Simplifying the dome electronics with the ReelTwo library

Whilst doing the write up of my NeoPixelPSI boards I mentioned the ReelTwo library by Mimir a few times and thought I’d do a post about how I’ve been finding it.

So what is the ReelTwo library? At its most basic, it tries to collect all the code for the various systems in a typical astromech into one place. This makes coding lights and servos a lot easier and quicker and standardises on the interface options such as i2c or serial communications.

In my droid, I’m using it on a single Arduino Mega in the dome to control *all* the lighting. This vastly simplifies the wiring, especially the power, and gives a single i2c address to send commands to.

What does it control in the dome?

  • RSeries front and rear logics, giving nice fading light patterns and the ability to trigger effects, etc.
  • FlthyHP system, tho this is really just three adafruit neopixel arrays in the HPs but does allow for expanding to control servos when I get them installed.
  • PSI boards, originally my RGBMatrix boards, but now my new NeoPixelPSI boards

All this from a single Arduino Mega with a sensor shield on it to give it an easy pinout. Previously I would have needed at least 3 different control boards, possibly with 3 different voltages and the associated buck converters. So this removed 2 arduinos, a power bus, an i2c hub, and a buck converter from my setup (I just have a 5v and 6v for the servos). It might not sound a lot, but removing the associated wiring made things a lot clearer.

Would I recommend people use the ReelTwo library? If the hardware you have in your dome is supported, then definitely! The more people using it, the better support it will get. Its been running in my dome for a few years now with no issues.

Next steps? I want to add a Pi Zero into the dome for some more functionality, running a satellite version of my r2_control software, but this will also give me a USB port to allow remote programming of the Arduino.

NeoPixelPSI – Using

So, you’ve got your new PSI boards and have them mounted in your droid, now you need to get them to do things!

Code Examples


My preferred solution is to use the ReelTwo library, however this may be overkill as its designed to run all your dome lighting (and more) from a single Arduino Mega. This is how I’ve been running my droid for the last few years and it works great whilst also vastly simplifying the wiring, especially the power. Feel free to give me a shout if you want to go over my setup. (Note to self, good idea to do a write up about it!)

Adding the NeoPixelPSI to an existing ReelTwo setup is a case of adding the include file, and specifying the PSI pins you used.

#include “dome/NeoPixelPSI.h”
NeoPixelPSI fpsi(3);
NeoPixelPSI rpsi(4);

By default, the PSI will be the colours for the front PSI. You can change the colours in the setup() function with:


This will set the rear PSI to the standard colours. Colours are specified in RGB values (0-255). The first value is 1 to set the first colour, and 2 to set the second.

Flash your code and plugging in your PSIs (with power off!) and you’ll have a couple of standard PSIs for your droid.

FlthyMcNasty HP Boards

Another option is to use some spare headers on your FlthyHP system. This is a great solution if you already use his HP system (and if you don’t, why not?! I use it, implemented in ReelTwo). All you have to do is take the example code from my github and plug in the PSI boards. The format is similar to the ReelTwo library, with the PSI defaulting to the standard front PSI behaviour and needing to set the colours in the setup function.


If for some reason you want to just use a standalone arduino to power your PSIs, I have done a breakout board that accepts a pro mini arduino and has some simple input/output headers to accept power and up to 4 PSI boards.

The code is functionally the same as both the FlthyHP and ReelTwo libraries, so just needs a bare minimum for changes. The code in my github will run two HPs as per the standard for R2.


The PSI code is written in an object oriented style, with each PSI being treated as an object. There are a few functions available to change the look/feel of your PSI

set_color(color, r, g, b)

As it sounds, this sets the colour of the PSI. If color = 1, then the rgb values are used for the first colour. If color = 2, then they are to set the second colour. These are used in the standard swipe animation. The RGB values are all between 0 and 255.


This accepts a value from 0-255, with 0 being off (why would you set that?) and 255 being blinding. A typical value is around 20-40. The lower the value, the lower the current draw.


Set the speed the colours swipe from one side to another. This is in milliseconds, specifying the time between each ‘frame’ of the animation. So a lower number is actually a quicker swipe. Typical value is about 75ms.


Use this to set the time between each swipe. Again set in milliseconds, and actually produces a random delay between the animations of between <delay> and <delay*4>. A typical value will be around 1500ms.


As a work in progress, I have also written a couple of simple effects with the idea being these can be triggered by an i2c command or similar.

do_random(cycles, pulse_speed)

This will flash each pixel on the PSI at a random colour and slowly over <cycles> the number of pixels that are flashing will reduce until the PSI is black. Useful for a ‘malfunction’ effect. <speed> is the number of milliseconds between each frame of animation.

do_pulse(pulses, pulse_speed, r, g, b)

A nice little effect that will pulse a PSI at a set colour, something like a heart beat. <pulses> is the number of pulses to do, <pulse_speed> is the delay between each frame (20 frames per pulse) in milliseconds. The RGB values are set between 0 and 255.

Note: Its colour, not color, but to make things easier with existing libraries such as the Adafruit Neopixel one, I spelt all the functions and variables in the code as color to keep it consistent. That hurt!

NeoPixelPSI – Coding

I had a bunch of my lovely new PSIs, and had tested them with a example sketch to make sure they all worked. Next step was to write the code to run them.

Initially, it was some quick and dirty writing to get an idea of how to do it. I used a map array to break it up into columns as the main effect will be a side to side swipe of colours. Thankfully, a lot of the code I could copy from my previous PSIMatrix project.

Once I’d figured out the basics, I wanted to make this portable. I’m a big fan of the ReelTwo library by Mimir, which lets you run the entire dome lighting (and more) from a single Arduino Mega. Vastly simplifies the wiring and power requirements. I also wanted to have it usable standalone, and also with the FlthyMcNasty HP system.

This all meant that I had to write it as an OOP class, something I don’t tend to do a lot. Thankfully there are lots of tutorials, etc. so after much bug finding, reading of documentation, and experimentation, I managed to get the whole thing down to where it is basically a library.

Currently supported options:

  • Standalone – You can run a single PSI from its own dedicated arduino. Tested with a nano, but should work on just about anything.
  • An option in ReelTwo – Just add a couple of lines to tell the software what pins you are using, and it will just work.
  • Extension to the FlthyHP system – The Flthy system has plenty of spare pins and is mostly off the shelf components, so I’m a big fan. A custom version of the sketch is available to tack on PSI support.

So far, I’ve had a couple of boards running for 48 hours as a burn in test and they all seem to be working great!

These will be getting tested in my droid soon, and I’ve a spare set for another builder to try. I also plan on adding a whole bunch of extra things, especially to the ReelTwo verison, such as different animations (pulsing heart, malfunction, other random things, triggered via i2c), ability to change the swipe speed/delay, and also change the colours from default.

It should also be possible to extend the RSeries logics by JoyMonkey to use these PSIs.

NeoPixel PSI – Designing the PCBs

Something I’ve been meaning to do for a while was look at how to do a PCB with SMD layout that is now offered by a few of the cheap chinese fab houses.

A bit ago I did some reasonably cheap PSIs for R2 using off the shelf components, and even added the support into the ReelTwo library. However, these still weren’t what I wanted. I’ve used the VADER PSI boards in the past, but the source was closed and I had a few failures with them.

So, last week I had the motivation to take a look at doing a simple PSI board using WS2812 RGB LEDs, commonly referred to as NeoPixels.

I decided to also give EasyEDA a try, seeing as it is a schematic and board layout system that is provided by my usual PCB manufacturer, JLCPCB.

Not only has it got a very quick learning curve, it also has a great library of parts and is well integrated into the whole manufacturing process. In fact, it only took me a couple of hours to get to grip with it and get a first pass of a board layout done!

With a few clicks, I had the correct parts selected and a Pick and Place file downloaded, along with the BOM. I took these over to the JLCPCB site and uploaded them to see what the cost was. With a minimum of 5 boards, it came out to about £20, and with a nice £5 off coupon I figured I just give it a go.

My first attempt had some issues with ambiguous layouts and the wrong components selected in the BOM, but the customer service was very helpful and cancelled the order so I could try again. My second attempt also let me put a nice R2 Builders logo on the back of the board. Thankfully it went a lot smoother this time and I soon had an order in and processing!

Now all I had to do was wait.

A pleasant surprise was that it only took a little over a week, and 5 nice new PSI boards, fully populated with 21 WS2812 LEDs dropped through my door. All that was needed was to solder a 3 pin header onto them.

A quick dig through my arduino tub to dig something suitable out, and I had an example sketch from the FastLED library running.

Next step…. turn them into actual PSI lights.

HO15 Sentry Droid with Autonomy

Well, its been a boring year with no droid outings, tho thanks to doing some live youtube events under the Droid Builders UK banner, we’ve managed to raise over £14k for CALM.

I know droid 2 isn’t finished yet (tho some slight progress has been made which I will blog about later) but I have decided to push my knowledge and skillset by building an autonomous droid. Nothing as big or heavy as an astromech, but a much smaller and lighter HO15 droid. These are a new one that was built by Oliver Steeples for The Force Awakens.

The droid is designed to be driven using omni or mecanum wheels which allow it to not only drive forward and turn, but also to strafe to the sides and generally move in any direction it wants. The type of drive system is called a holonomic drive.

Originally I was just going to build it with standard RC controls, but after seeing a few articles and presentations about ROS it got my ambitions up! ROS is Robot Operating System, and whilst it isn’t technically an operating system, it is a very mature platform for developing robots on. As well as driving the droid it can also do navigation, obstacle avoidance, and even 2d/3d mapping of its environment.

So, the idea is:

  • Styrene HO15 droid, as accurate as possible.
  • 4 omniwheels as the drive.
  • Multiple (8?) ultrasonic range sensors to detect obstacles.
  • Xbox Kinect camera/sensor to detect 3d space infront of the droid.
  • RPi cam for remote operation.
  • Autonomous random movement – I can leave it to wander and it will just meander about the place, avoiding objects.
  • Directed movement – Take control of it directly to drive it, but still avoid objects as a safety measure
  • And even full mapping and navigation, tho this is definitely a stretch goal!

Central control will of course be a Raspberry Pi running Ubuntu and the latest version of ROS2. The original ROS is being rewritten and will be retired in the next year or so, so I decided to push forward with version 2 from the start. Unfortunately, this causes complications as most tutorials and packages are still designed for version 1. But then, I like making life difficult for myself!

Big printers

I’ve just done a post over on my other blog (seeing as it wasn’t R2 related), but it is going to be used a lot for my droids over the next few months.

So head over to read about the upgrades I’ve done on my CR10-S5 printer

Two years of Omnis!

I’m just about to do my first event of the year, and realised that two years ago at the same event, the organiser posted this picture:

Setup time for Bolton Comic Con – NWCC

This picture filled me with a sense of dread. Why? Because up until this point I had been running a single castor setup in R2’s center foot and I knew that with that in place my droid may as well have been a static one on a carpeted floor like this.

However, I had recently updated to an Omniwheel setup, using wheels from Vex Robotics.

With fingers crossed, I went to the convention and was so happy to discover that the omni wheel handled it all with no issues. I could turn, reverse, even spin on the spot with out a single problem. I had a great event and put plenty of smiles on faces.

That was two years ago and they’re still going strong!

A little dirty, but still good!

These have been over lovely smooth gym style floors, deep pile carpet, hard concrete, cobble stones (that wasn’t fun!), asphalt, pretty much any hard surface. Even driven through snow! Dozens of events, with a heavy weight droid of 60kg, and a very cavalier attitude of where I drive. In fact, the majority of the time I prefer to unload at a carpark nearby and drive him to the event.

Since replacing these I am now onto my third set of drive wheels (latest set are hard Vex colson wheels) but haven’t had to do a single thing with the center foot apart from a little bit of fluff cleaning.

Are there any downsides? Not that I’ve found. You do get a rumble that is really noticeable on wooden floors like gyms or village halls, but I actually like that. Feels very solid.

By far, this is one of the best upgrades I’ve done to the droid since his first event outing in 2017. Since then his main drives have also been upgraded to Vex parts, with hex bore Colson wheels holding up a lot better than the previous ones I had.

Now to get the batteries charged and ready for the fun times on Saturday.

Uniting the Builders

Recently I’ve been involved in a new project to unite all the different droid building clubs in the UK under a common umbrella. Hopefully to help share ideas and also get more than just R2 units at events.

R Series astromechs always go down well, but it would be really good to get some BB8s or MSE droids there too.

To this end, we have launched a new site:

Droidbuilders UK

We recently had our first meet up under this banner in Camberley. You can read a write up about it here.

So, if you’re building any type of droid from the Star Wars universe, pop along and see the site, and also join our Facebook group for chats with other members.

This isn’t designed to replace the current forums/groups/sites for the various builder clubs, more as an attempt to unify them all.

Show your driving skills

At last years R2UK event, the driving course was introduced. Originally by Colin Barker and Lee Towersey, built out of wood with 3d printed bumpers it went down a storm. It got rolled out a few times over the course of the year and I added the times to the MOT site.

I’m not one to let things lie tho. Times were manually entered into a spreadsheet, with any penalties added in by hand.

Not only that, the course took quite a while to strip down and put up due to all the power cables needed for the bumpers and gates.

This was where I come in. I was sure that I could help streamline the process and it was a nice project to work on. Along with my work, Mark Leigh and his brother started working on rebuilding the course out of aluminium box section to make things a bit sturdier.

I at least wanted to remove the need for all the cables going to the sensors, as this was a big pain in the setup, and was a bit of a mess. Whilst I was at it I came up with the idea that we could easily make them wireless so that when they’re triggered it automatically reports back to a central hub.

From there the ideas expanded! I didn’t want to have to redesign and reprint all the parts so everything had to reuse the physical bits. A Raspberry Pi would be used as a central hub to keep track of the times.

In the end I used a Wemos D1 Mini for all the sensors, as they were cheap and had more than enough I/O pins for what was needed. Both the bumpers and the slalom gates have the same electronics in them. The timing gates that start/stop the clock were microswitches but had to be reset each run so I switched these for ultrasonic range finders.

Finally, the clock got a major upgrade. Initially it just sent a signal to the Pi to say that the clock had started, but I quickly ran into latency issues. Due to this, the main timer for everything is not the Pi but the big clock itself. The timing gates are hardwired in and when they are triggered the clock sends the time back to the Pi in its API call.

So the Pi is using the same Flask python module that r2_control is using, I was already fairly familiar with it and it made creating an API very easy. The Pi is responsible for displaying and storing all the details about the runs, with Pi Zeros being used to display the various pages on monitors around the course.

As a final touch, I went really fancy! To register what droid and driver are about to do the course, they can now swipe an RFID tag. I built a simple reader with screen so that once the droid is ready to start they just swipe their tag over the reader. At R2UK there were some issues with writing tags which have since been solved. Even better, the new Builders ID cards have RFID chips built in.

Video courtesy of Rob Howdle

It took a couple of hours to work out some bugs on the course, some my own fault and others hardware limitations (seems the Pi’s onboard wifi wouldn’t allow more than 10 clients) but I worked around them and after that the course seemed quite popular again. Just need to write some better documentation and program up everyone’s ID cards.

Next step is to add another type of sensor… a shock sensors. Some people started getting quite competitive and the course was starting to take a few knocks. So a couple of accelerometers will hopefully make it back into a driving accuracy course!

All code is in the Builder’s github repository:

Motor Movement!

Well, the connectors didn’t turn up on Saturday, but they did turn up today! So after a bit of crimping, and a bit of soldering (and a few mistakes, but we won’t go into that) I had a couple of cables made up to allow me to connect the Q85 motors to the ODrive.

Here is one of the sets of cables. They consist of the red wires in the back that go to an MT60 connector that carries the main signal to the motors, and then another bunch of wires that come from the hall effect sensor that is embedded in the motor. This tells the controller where the motor is in its cycle, so that it knows which coils to energise.

Also needed were some capacitors across the sensor terminals to cut down on some noise. Instructions for doing this are here:

With all that in place, I gingerly powered it all up and set about calibrating everything. I followed a guide on the main astromech forum, along with the odrive guide for hoverboards (same principal as driving an astromech it seems). It took a bit of trial and error, that I’m hoping to iron out into a proper tutorial at some point, but the motors were eventually running!

The mixing that I’d done in software all looks like its working as intended. I can also bump the speed up incrementally, as I can with R2, but with a lot more control and accuracy.

I do need to change the ramping settings on this, which I may even make changeable on the fly from the controller. Also the multiplier may need some tuning to set top speed, but that will require some testing in situ. I need to push my changes back into github, and make sure that R2 still works with the new code.

I think this brings the electronics to a good resting place for now. Just going to tidy up some of the cabling and add a volt/current meter. Its time to concentrate on making the actual droid. So this weekend it will be time to don the breathing mask and start glueing everything together.