A few people have expressed an interest in my r2_control system, so I thought I’d do a post about how it works, and what it needs.
At the core is a Raspberry Pi 3B+. This runs the main code, and also any programs to interface controls (PS3, Web, Instant Messenger). It also acts as a wifi hotspot.
From this Pi you can add a Sabertooth 2×32 and Syren 10 via USBSerial to allow control of those using packet serial communications. A python library for which I have written to make things easier.
Recently, a GPIO option has been added to the core code so that you can trigger relays and other switched items directly from pins on the Pi. I use this to trigger the relays that break the connections to the foot motors and dome motor.
Lastly, an i2c connection is available for communicating with various other boards such as the Adafruit 16 Channel PWM controllers, RSeries lights, ReelTwo system, etc.
A basic system to have simple control over a droid with no opening panels and no triggering of dome light sequences can be had with just:
1 x Raspberry Pi 3B+
1 x Sabertooth 2×32
1 x Syren 10
1 x USB FTDI (For USB interface to Syren 10)
1 x PS3 controller (Or PSMove)
Whatever dome lights you wish, eg TeeCees.
Battery
Power distribution (Fuses, power switch, etc.)
2 x Drive motors (eg. 100W Scooter)
1 x Dome motor (eg. pittman)
You can run the Pi from the BEC built into the Sabertooth if you wish, but I do recommend at least a 2A buck converter on its own fuse.
If you want to run any servos, you can add the Adafruit PWM controllers onto the i2c bus, up to 6 can be added by configuring the address jumpers. One in the body and one in the dome is usually enough.
This system can of course be added to. Relay control over the motors, light sequence triggers, and other gadgets such as smoke machines.
The current state of PSI displays from the club are either simple TeeCees ones, or the VADER boards. I’ve had a couple of the VADER boards in R2 for a while, but recently I’ve had issues with some of the LEDs failing. Unfortunately, as these are WS2812 addressable LEDs which means when one fails then you can’t communicate with any further down the line. They are also all surface mounted, so not exactly easy to replace, especially as they are so closely spaced. On top of this, they are not open source so I have been unable to do any fun stuff with i2c triggers.
I wanted to build some PSIs from off the shelf parts and allow it to do some more interesting effects. After a lot of hunting, I finally found some i2c addressable 8×8 RGB Matrix displays from Seeed Studios. Couple one of these with an Arduino Pro Mini, and you have a relatively cheap PSI using standard components.
Arduino Pro Mini (https://coolcomponents.co.uk/products/arduino-pro-mini-328-5v-16mhz)
Header pins for the arduino (not necessary)
Circuit
Not really much to the circuit, just using the pro mini i2c pins to talk to the rest of R2’s i2c bus, and then software i2c on another couple of pins to talk to the display. This has to be done as the displays have a fixed i2c address of 0x65, so only one can be on the bus at once. This also allows the rendering of the display to be offloaded onto the arduino.
The display comes with a short cable which you can cut the end off and solder directly to the pro mini if you wish.
Currently, when powered on the display will just do the standard left/right swipe of two colours (all configured in the arduino code). Also, two functions have been added to either pulse a heart or do a random pattern to simulate a malfunction. Others may be added at a later date, feel free to suggest ideas!
The heart doesn’t really show up too well through the diffuser, but it still looks like a pulsing pattern, so I’m happy with that.
The random malfunction will take an integer number of cycles and randomly turn pixels on to a random colour on each cycle. The number of pixels that are on will slowly reduce to zero. Ten cycles is about 1 second
To trigger these effects, you send an i2c command to the address defined in the arduino code (typically 0x06 or 0x07) with either H or M as the first character, and then a number of cycles (1-255).
I have implemented this into my r2_control software, which allows me to script actions together. The plan is to do something like trigger the malfunction sound, set the PSIs to malfunction mode for enough cycles to cover the sound, and also flap all the panels in a pseudo random way.
Installation
I have a set of Ultimate PSI Housings from IA-Parts, which hold both the standard teecees boards, and the vader ones. To fit the square peg (rgb matrix) into a round hole, I knocked up a very simple 3d print.
This clips in nicely to the PSI housings, however you may have to do your own system.
Summary
I’m actually quite pleased with these. Its really hard to find a densely packed RGB matrix as an off the shelf product. After much searching this was only one I could find. Its by no means as nice as the custom VADER boards (and I know others in the community are working on their own), but it does work and looks a lot better than the TeeCees ones (IMHO).
Not only that, its cheap too at about £25 per PSI (not including any costs for making the mount, but in my case that was a few pence for a 3d print)
Next step is to figure out some more fancy things I can do with it, and maybe add a selector jumper so that you don’t need to change the code between the front and rear PSIs. I may also do a custom board to connect it all together in a neater form factor.
For a long time I’ve wanted to make a much more stealthy method of control. When I first started R2, I’d considered using a Wii remote and nunchuck, but I realised that as I’d already done the PS3 controller code, it wasn’t that much different to use a PS Move navigation controller. They show up as a standard joystick in Linux, so easy to interface with.
As the code for this wasn’t going to be changing much from the ps3 code, I pretty much just copied it over to give me a foundation. Currently it only supports a single navigation controller, but the plan is to allow two controllers to give me more options and things I can trigger.
The main drawback at the moment is the lack of dome control, but that just gives me more reasons to finally get round to doing some automatic dome functionality.
Battery life is an unknown at the moment, and as with the ps3 controller it doesn’t seem to charge unless plugged into a computer.
Along with doing this code, I also worked on getting it easy to switch between the different control systems. There is now an API call to list and select a different joystick, with options to call it via both web and telegram at the moment.
The last few days have been spent doing some fairly major refactoring and other code improvements. I wanted to add functionality for the FlthyMcNasty HP control systems and realised as I add extra API calls, then the main.py code would start to get a bit unwieldy.
To this end, I started learning about Blueprints in the Flask web framework I use. Blueprints allow API calls to be added functionally in a modular fashion. This meant all the API definitions and functions could be brought out of main.py and into the actual script for the device in question.
Along with this I learnt how to dynamically import code into main.py, which coupled with using blueprints has given me a much more modular approach to adding various devices.
Now, plugins can be loaded by just adding them to a line in the config file. They will then be dynamically added on startup. This is going to make it a lot easier to add the various modules such as the PSI, logics, Charge Bay, etc. to the API.
The last few updates have added some much needed core functionality that makes this code work well for basic driving at events. Future versions will improve on this and add extra modules for more fancy items.
With this release, the following functionality is working, having been tested at a number of events over the last few months.
Sounds – 486 MP3 tracks installed, and easy to add more.
Servo control – Can add Adafruit 16 channel PWM controllers and control many servos for opening doors, etc.
Web control – Built in web interface to do basic controls and testing
PS3 controller – The PS3 controller is working well, interfacing with the r2_control API to trigger sounds, servos, scripts, etc. It also interfaces directly to the motor controllers for movement.
There is also some WIP functionality that I don’t class as core.
Monitoring – got a POC of system monitoring (voltages, currents, etc.)
Telegram – Communication and control over instant messenger
I’ve many plans for future expansion of r2_control for version 2.0, which I will hopefully get time to do in the coming months. These are just some of them:
Refactor of PWM code using updated Adafruit I2C libraries
Add modules for rseries logics and flthy HP systems.
Finish the monitoring system
Switch the dome control to packet serial rather than PWM servo control
Move dome control into core r2_control, rather than direct from PS3 controller
Auto dome (auto center, turn, etc.)
For now, there are too many events coming up to be able to risk taking R2 out of commission, so most of the work will be on tweaking the actual droid and tidying things up.
The temperature is getting low, and after spending most of saturday getting numb fingers and feet whilst working on R2’s center foot, I decided to do some much warmer work in the office and do some code enhancements.
Telegram Bot
i2c Monitoring
Drinks Mixer
Telegram Bot
Telegram is a communication system that I already use for my home automation, so figured it might be handy for R2 to use it to. Not many functions added yet, just some simple volume and sound commands, but the main function is the /status command.
Current Status
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Uptime: 14:26:25.870000
Main Battery: 24.865 (balance: 0.011)
Remote Battery:
Wifi:
Internet: True
Location:
Volume: 0.296875
--------------
Scripts Running:
Still some clean up needed, but gives a good way of checking various stats.
i2c Monitoring
This is something I’ve been wanting to add for a while, and have had the circuit and basic arduino code done already. It is all now tied into r2_control and so current draw and battery status (current voltage and max cell difference) can now be queried. Not only that, if logging is enabled then it will also log to a file twice a second (configurable) as a csv. This means it can be imported into a spreadsheet and graphed so I can see power draw throughout the day.
As can be seen above, the details can also be retrieved using the telegram bot and /status.
Drinks Mixer
Not so much part of R2 exactly, but it will be going into him. The plan is to have a few reservoirs, some pumps, and some control circuit to allow drinks to be mixed and poured.
A base outline of code is now done, which will take in an array of substances and amounts, and turn a set of i2c controlled motors on and off for the desired duration. Still lots to do on this, not least of which is to get a working circuit done, and a decent web interface, etc. But its a start.
So, all in all I’m rather happy with a mega weekend of hacking at R2. May try to get out to the garage one evening this week to do some more work on his center foot. I’d like to have it ready for the midnight premier of The Last Jedi that I’m attending. Trouble is, the garage is currently sat at around 4.5C.
After a recent discussion on the facebook group, I thought it was time to finally document the internals of R2 as best I could.
Not the most elegant of diagrams, but it does the job.
The battery is made from 18650 cells and gives out about 24v. I did a write up about this over on my personal blog. I’ve managed over 6 hours on a single charge of my main battery, most of the time was spent rolling around an event too.
All power goes through a central fuse box. Each part of the droid has its own fuse of various ratings. A single DPST switch handles turning R2 on and off, with a couple of meters to monitor voltage and current.
The main drive systems all run on 24v to give maximum torque. Each motor is connected to the speed controllers via a relay, controlled from a relay board. This gives both the ability to remotely control the power to the drives, and a safety feature of breaking the circuit to the motors if there is no battery in place. Without this, its possible to blow the speed controller if the droid is pushed whilst no battery to take the regenerated power.
The Pi is the main brain (currently a Raspberry Pi v3), running the r2 control software I’ve written. The vast majority of the control is over i2c, talking to various modules in R2. The main i2c module is an Adafruit i2c 16 channel servo controller. This controls the servos that open the various panels, as well as the signals to the speed controllers. A couple of R/C switches control the power to the drive relays. i2c is also carried through to the dome for controlling anything there.
Lastly, audio is taken from the output of the Pi into a dedicated amplifier and stereo speakers.
I’ve tried to keep it as simple as possible, but with so many options it isn’t always easy. The main thing I wanted to do was keep everything to 24v for as long as possible. With this current setup the body just has two automotive voltage converters, one to power the Pi, and the other to give dedicated 6v to the servos. Everything runs a common ground to simplify things, and also minimise communication errors.
There are many options for a battery to power an astromech, from the tried and tested Sealed Lead-Acid, to the latest LiFePO4. This article will look at utilising the very common 18650 cells. These are used in power tools, laptops, even Tesla cars.
WARNING, this article will talk about opening old packs, harvesting their cells, soldering cells, spot welding cells, and lots of other things that could be quite dangerous.
Lithium cells of any type can heat up or burst into flames if mistreated. Only attempt the things in this article if you are entirely comfortable with any possible outcomes. Do other research, read other articles, the author accepts no responsibility for any injuries or death from the instructions given.
General theory
18650 refers to the size of the cells, 18mm x 65mm. They generally have a capacity between 1500 and 3500mAh. If you see anything saying 4000mAh or above, chances are its a scam. There are a lot of cells branded ultrafire that claim over 6000mAh capacity which is a total lie. Voltage ranges from 4.2v when full, to 3.2v when empty. These cells use Lithium-Ion technology, which is a lot safer than the Lithium Polymer that is used in many radio control devices. The drawbacks are that it has a much lower discharge rate. LiFePO4 are even safer, but are also more expensive. Li-Ion seems to be a middle ground, which is why it is used in so many places.
Generally, these cells are arranged in series/parallel to get the desired voltage and capacity. For example, a 24V battery is made of 6 cells in series. Extra capacity is added by putting more cells in parallel, so that if you use cells with 2500mAh capacity and want a 24V battery with 10Ah capacity, then you will use 4 rows of 6 cells, commonly written as 6s4p.
The current drain allowed on a battery is usually 1C, or 1*<capacity>, so in the same example 6s4p battery, you can have a maximum drain current of 10A. Doubling the battery up to be a 6s8p will give you 20Ah and a 20A potential drain. 1C is the safe limit using recycled cells. If you are using brand new cells then you may be able to get a higher current draw by checking the datasheet. For example a NCR18650B can draw 2C and a NCR18650PF can go up to 3C.
Sources
Cells
As mentioned above, 18650 cells are used in many places, and can generally be recycled. The best place I have found for second hand cells is from laptops or power tools. These battery packs can be cracked open and the cells removed. It is quite a labour intensive task, but saves a lot of money. You can pick up job lots of second hand cells from eBay, tho this is getting more expensive as more people are harvesting cells this way.
You have to force the two halves of the battery case apart, usually with a screwdriver or similar flat sharp object, and then separate the cells from the circuitry and cabling inside. Always wear heavy gloves, and take extra care when using a lot of force. Its easy to slip and damage yourself or the batteries. Also make sure to take care not to use the cells as a fulcrum as this will also damage the cell. Basically, be careful and take your time.
An Opus BT-C3100 18650 charger/tester
The drawback is that each cell is of unknown capacity and life, some cells may even be totally dead. They could already have been through a few thousand cycles. Each cell needs its capacity testing with a charger/tester such as the Opus BT-C3400. Of course, if you can ask friends and family for donations of old laptop batteries, you can save even more money. I managed to get a lot donated for free. Despite the drawbacks and amount of work required, you can end up with a battery for next to nothing that would cost a lot if you bought a ready made one. For example, I built a 24V 25Ah (approx) 6s11p for around £50 of cells, plus a few other bits.
The other option is to buy brand new cells in bulk. Either from Chinese sites such as aliexpress.com, or from other sites closer to home such as eu.nkon.nl. Chinese ones are generally a little cheaper, but you do have a long lead time and the risk they are counterfeit. A typical cell such as the NCR18650B (high capacity/average discharge rate) or NCR18650PF (medium capacity/high discharge rate) can be bought for approx £3 a cell.
Additional
As well as the actual cells, there are a couple of other essentials. These are cell spacers, which clip into various configurations to hold the cells in place, and allow air flow around them. You’ll also need nickel strip to connect all the cells together. Both of these items can be bought from aliexpress.com in bulk. If you are buying brand new batteries from NKON, they also sell nickel strips for a decent price when bought in batches of 10m.
Lastly, you’ll need battery connectors and a balance lead. The battery connector can be anything you wish, as long as it will take the current. The balance lead is a connector so you can make sure that all the series cells are at the same voltage. This is important so you don’t let one cell run down lower than the others, which will potentially damage the cell, and maybe the whole battery. You need one for the correct size of battery (eg, a 6s battery will need a 7 wire balance lead) which can be got again from aliexpress.com or ebay.
Constructing the battery
Once you have enough cells together, and all the other items, time for construction. The general process is:
Sort the batteries into parallel sets with the same total capacity. The idea is to have them well balanced before you even start. You can use a site such as repackr.com to help with that
Clip the cell spacers together in the required layout (eg 6×12 for a 6s12p), then lay the cells out. Each parallel set should be the same orientation (eg, negative to the top), but alternate them as you fill in the series set.
The start of a 6s12p pack. Can see the parallel sets run down the picture, with the series sets alternating across
Once you have all the batteries in place, clip the top of the frame into place
Here is a small 3s5p pack, ready for the nickel strips
Now its time to connect the parallel sets up. Using either a soldering iron, or a spot welder, connect strips along all the parallel sets. These are the ones that are all the same way up. What this does is create the capacity for battery pack. Be careful if soldering, don’t allow too much heat to build up on the cell, do it as quick as possible. You can get spot welders from aliexpress.com for around £200 that will do the job a lot better.
You can also get a device that will give you a full readout, just from plugging the balance connector in. They are only a few pounds from places like ebay. They will let you view the total voltage, each parallel set voltage, and also the max/min/dif between the cells.
For the initial charge you will need to use a decent balance charger, such as an imax B6. These are generally for lipo batteries, used in radio controlled quad copters or planes. The benefit of a charger like this is that it will balance the cells out and has lots of monitoring and protection built in. Follow the instructions in the charger manual closely.
Testing
Once charged, leave your pack for a while, even a month, testing the voltages periodically. If you have a dead cell, then it can manifest as one of the parallel sets slowly loosing charge. When this happens, you’ll have to dismantle the battery and retest all the cells.
If you have the time, you can also do a full discharge test with the charger on the battery to get an accurate reading of its capacity. This will take a long time if you’ve made a big battery, depending on the charger you use. If you aren’t overly bothered about an accurate capacity test, just run the battery in the droid (or whatever other use) and monitor the voltage. Don’t let the voltage go down below 3*<number in series> (eg, a 6s should never be let to dip below 18v). To prolong the life of the battery, don’t even let it go that far. Full charge/discharge cycles are the worst case for wear on them, and will shorten the lifespan. I recommend discharging it to around 40-50%, at least on the first try.
After the first discharge, check the balance of the cells again. Ideally there should be little difference between them in a fully functional battery pack. If there is significant difference (IMHO, 0.1v between the highest and lowest voltage) then you may have a bad cell somewhere. Do another balanced charge and discharge cycle and see if the same cell has troubles. If it does, rip it apart and try again.
If the battery remains balanced, then you can actually use a none balance charger (cheaper, and usually higher current for rapid charging) for most charge cycles. Tho make sure it is balanced occasionally and no harm in doing a slow balanced charge once in a while.
Conclusion/Notes
Using 18650 cells gives you great flexibility in not only the size (voltage and Ah), but also the shape. This example has shown creating standard blocks, but with some creativity you can make a battery that follows a certain shape (ie, follows the outer curve of an R2 unit’s interior). If you want to make use of recycled cells, then this is a very cheap option to get some very high capacity batteries built. Even buying brand new cells will still save you a lot of money.
For example, I’m currently building a 6s12p pack using NCR18650B cells. I’m getting these for approx £3 a cell. That makes the total cost of cells £216, which gets me a 24V/40Ah capacity battery in a fairly small form factor that can give out nearly 80A (my droid barely pulls 10A at full speed!). I doubt I could fit enough SLA batteries in my droid to get that, and a similar capacity of LiFePO4 would set me back about £800. Even taking into account the cost of a spot welder (which can be used many times of course) its double the price.
Further research
One thing I haven’t covered in this article is a BMS. This is a Battery Management System makes sure nothing is going wrong with it, and will cut off the output when the battery gets too low. I’m still researching these myself, and will possibly mess with them on my next pack. IMHO, if you are keeping an eye on the battery voltage during use and doing periodic balance tests and charges, then a BMS is not necessary.
Also note that capacity of the cells will drop over time, depending on number of cycles, how deeply they were charged/discharged, and how rapidly they were discharged. Take care of the battery, and it will last longer, drain it constantly at high current and it will be dead within a few hundred cycles.
Its been a long time since an update, but we moved house at the start of the year and things have been hectic. At least, thats my excuse and I’m sticking to it! I have been making progress with R2 in the last couple of months, doing a lot of work on his brain for starters, and painting various parts.
Code wise, there has been a couple of fairly drastic rewrites since my last update. The interface is a REST API, which sends commands to various modules as before. I’ve added a scripting module now, so that scripts or loops can be initiated such as random sounds, or a dance routine. The servo module had to have a major rewrite too as I discovered that I could only control one servo at once and had to wait for that to finish before another command could be sent. That wasn’t much good! I’ve also written the first of the actual controller interfaces (not counting a simple web one for testing), R2 can now be controlled from a PS3 controller. Button combos are read in from a csv file to trigger certain effects or scripts. Lastly, R2 now has a voice, and can play any mp3 stored in a directory, including selecting random ones from a list of types. Next step is to get either the Pi or the A la mode Arduino to control the speed controllers. I don’t want to run them off the Adafruit i2c servo controller for safety, I’d rather drive them directly and have some form of watchdog to make sure R2 doesn’t go on a rampage. All the code is still available on GitHub under my user, dpoulson
The PDU also needed a rethink, not least of all because of the amount of current it needed. The setup now has feeds directly to the speed controllers, with relays on the output from them to the motors so I can break the circuit if needs be. These relays will automatically turn off if the battery is disconnected so that any pushing of R2 will not feedback into the speed controllers and fry them. The relays will also be controlled from GPIO pins on the Raspberry Pi so I can disconnect them via an API call. I’ll also have an input for a kill switch that will have to be permanently on if any of the motors are to be powered, possibly using a transmitter in a replica droid caller or hilt of a light saber. I’ve a base idea for the new relay controls:
The relays I’ve found are Omron G4A-1EA, which have the benefit of the switched load being on spade connectors on the top, rather than through PCB traces, which when I did the calculations would need to be massive to support the potential current running through them. This allows me to make a simple PCB with the controller circuit, and hook the 24V battery up to it to power the coils. If the battery is removed, the coils turn off and the circuits are broken. No fried speed controllers.
The 24V connection will probably go through the fuse box I’ve installed, with a hefty fuse. The makers of the speed controllers don’t actually recommend a fuse but I’ve seen a few comments saying a 60+A fuse can’t be a bad idea, just in case!
The battery will connect directly to the center contacts of a DPDT switch, with the fuse box on one side, and the charger connection on the other. This will allow charging the batteries without taking them out of the droid. Not sure if this is best practice or not, needs more research. Currently they are just a pair of 12V SLA batteries that I had, connected in series to give the full 24V.
I’m hoping to get some time either this weekend or next, to hook up the motors, speed controllers, and battery, to test them out and get an idea of potential current draw. They’ll be controlled with a standard RC transmitter/receiver for now. If I can get the legs onto R2 he may even be drivable by xmas.
