Most people start by building their droid, then doing the electronics. I’m pretty much doing it all in reverse.
Here you can see all the electronics for R2. The left hand board has all the main power, and the right hand board is the actual electronics. Both boards have edging around them, and will happily sit back to back, making the whole system easily removable. It also means that once removed, it can be opened up as shown to be worked on.
Wiring is nearly complete for the core parts (Pi, Odrive, and Amp), I just need to get an XT60 soldered on to accept a battery. Now, I know I’ve a load of XT60 connectors somewhere in my office, but so far they have eluded me. They must be somewhere *really* safe!
Also, at the top of the pictures you can see the stripped down Q85 motors, getting modified to freeze the clutch system.
Next step it to get power to the Pi at least so that I can start installing the brain. It will also be an opportunity to get the documentation improved, and initial config sorted, incase anyone else wants to use my code.
Oh, and I think I’ve decided on a name for my droid.
R0-S3, or Rose to her friends!
One of the things I’m quite interested in keeping an eye on (and wish I’d started making notes a lot earlier) is how much battery power I consume at an event.
R2 is quite a heavy droid, with lots of gadgets, and is generally very active at events. I like to drive round and entertain rather than staying in one place. I also may have gone overkill on the battery, tho that being said by never fully depleting the cells I’ll probably get a lot more life out of the packs.
So, I have started a spreadsheet to keep track of how much actual power I use in a given event, to hopefully get some meaningful stats for my droid(s).
Besides standard stuff like the event name and date, I’ll be logging the amount of power put back into the droid after the event, as measured by the charger I’m using. I’ll also log approximate hours the droid was powered up, along with how much of that time he was actually active and moving around.
The spreadsheet will be public, as it may help other builders:
I just have to remember to keep it updated now! 😀
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.