Software mixing

Currently, my PS3 controller code uses the channel mixing built into the Sabertooth speed controller. This means that I send it speed and turn commands, and the speed controller mixes these to drive R2 in a tank style, where you vary the speed in the feet to go forward/back or turn.

The problem with this is that not many speed controllers do this, so I am very much tied into using the Sabertooth with my code and the Sabertooth doesn’t support brushless motors. Droid 2 is going to use an ODrive, which has no mixing built in.

Well, until now!

I’ve abstracted out the speed controller portion of the code and added a function that takes the two axis from the drive stick and then outputs the required motor speeds. In this video you can see when I push the stick forward, the top number changes to show the position of the axis, and motor 1 is set a signal of 1, or full speed forward and motor 2 gets -1, or full reverse. (Remember, the motors are flipped)

I got the bulk of the code from here:

https://electronics.stackexchange.com/questions/19669/algorithm-for-mixing-2-axis-analog-input-to-control-a-differential-motor-drive

which uses cartesian to polar (and back) transformations.

I still need to hook up the motors, I’m waiting for some connectors to turn up, to check that it actually works and to do the code changes to send the correct signals, but this is a good step forward.

The other benefit to this change is that now I’m not limited to dual motor controllers, and can look at buying cheaper single controllers with a lot less smart technology built in.

Preston Comic Con tomorrow, so R2 and I are out all day, but if the connectors turn up that I’ve ordered, sunday will be a day of connecting and testing the motors.

Inside Out

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!

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 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.

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.

https://github.com/dpoulson/r2_control/releases/tag/1.0

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: 
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.

Summary

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.