Stealthy control

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.

Code refactor

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 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 and into the actual script for the device in question.

Along with this I learnt how to dynamically import code into, 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.

Release 1.0 of r2_control

After a few false starts and more or less total rewrites, I have decided that the core functionality of r2_control deserves a 1.0 release.

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.


Weekend of code enhancements

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.

  1. Telegram Bot
  2. i2c Monitoring
  3. 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: 
Internet: True 
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.

Electrics Overview

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.