It’s been a long year, with a lot of other stuff happening in my life, but I’m finally starting to work on this project again. 🙂
It’s time to get the show on the road for the SoapBox proof-of-concept mark 2. You already saw the mark 1 going in circles, proving that the differential traction system works well enough, now it’s time to rebuild it to allow full and precise control as well as regenerative braking.
With that in mind, I looked in my workshop for parts to build an embedded control system capable of mastering the physical problem. I have an extra Openmoko Freerunner motherboard with dead GSM and dead LCD lying around, and this will make a very good development platform for the SoapBox controller.
It has a few goodies for me:
– ARM32 system-on-chip running at 400MHz;
-128MB RAM and 256MB Flash EEPROM;
– 2 x three-axis accelerometers and aGPS receiver;
– accessible I²C and SPI bus;
– mini-USB (Host or Device) port;
– integrated Wifi and accessible serial debugging port;
– a thriving variety of Linux-based Operating Systems in concurrent development, supporting pretty much every development language out there.
So here’s the hardware development platform layout for this incarnation of the project (click for larger):
The hairy part that will need some sorting out right away is the power supply. I need to figure out how to feed the Freerunner and the USB Joystick from the main traction battery. I suspect some DIY electronics will be in order…
I’m inclined to use the SHR-unstable distro because I know it rather well from over one year of continuous SmartPhone use, and it will be relatively easy to customize. I tried building the complete Bitbake/SHR-u development environment so that I could customize lean-and-mean flashable image and develop the application in a native language such as C or C++, but after a whole week of fighting against that setup I decided to follow NJay’s advice and just use Python. 🙂
The Python interpreted language runtime is available out-of-the-box on the SHR distro, so the develop-test-correct cycle should become very fast, and time is of the essence when you don’t have any. Besides, it’s a lot more fun correcting an algorithm when you are actually riding it in almost real-time!! 😀
Speaking of real-time, I believe Python at 400MHz should be good enough for this kind of control application. In order to make all the CPU cycles available to my control application with the least effort possible, I’m planning on flashing the latest SHR-U image onto the phone and then removing all the unnecessary applications from it with simple “opkg remove” commands. It shouldn’t take much experimentation time to make a nice script that does it in a single step.
The X-server and all the GUI programs are going out, and probably all GSM and PIM daemons too. The Power Management bits should also go away, I don’t want it to go to sleep in a curve. 🙂 In the end, I’m probably leaving the D-BUS services that may come handy in the future, like the GPS and Accelerometer services. It should be quite easy to assemble a Python control application on top of that. Plus, the wireless network stack is handy for a remote telemetry link.
Here’s the planned layout of the software architecture (click for larger):
Obviously, the Freerunner cannot control the full power of the motors. So a couple of medium-power H-bridges are necessary. Here I have a little choice: I’ve asked my friends JBass and NJay to make something that can handle 24V & 20A and be controllable via I²C. If all else fails, there is also Devantech’s MD03 power bridge in the web shops.
I’m aiming for flexibility in this first iteration, I want to be able to experiment with the various H-bridge triggering modes and find out which is the best compromise between tight control and motive and regenerative efficiency. After that, it will be time to build up the complexity of the control algorithm and start adding smart controls like traction control and inertial compensation in curves, etc.
Fun is rolling our way. 😉