So as part of a larger project, that shall remain unspecified for now, I required a miniature vehicle that could be controlled from a PC over a wireless connection.

I work with Jaguar Land Rover so I do feel a modicum of affection for the sponsor of my doctorate, alongside an all encompassing ball of rage so I went and bought this:

The above is a licensed 1:24 scale CMJ RC CarsTM Range Rover Sport RC Car. It cost me personally £12.99 in case someone wants to copy this method in future (looks off into a future where that might be the case).

Key to the function of this type of remote control vehicle is the controller board that will employ a simple 2.4GHz spread spectrum control scheme... (if ya want me to break down the functionality of this board at some point let me know 😊 )

Oh just like that that one... I went right at it with the wire cutters didn't I?

That just leaves the simple mechatronics that are used to steer and drive the plastic chassis around (and some extremely simple wiring for powering the whole thing).

The RC car's bare chassis... Two motors, one to power the rear axle and the other (non servo) through a simple geared translational gearing setup to provide steering.

So far, I've bought a cheap £13 RC toy car, ripped it open (harder than it would appear), cut out the controller board with my trusty wire cutters and now I've got a broken toy...

Now to adding back in the type of wireless control that I want to use rather than that cheap controller board that 🤔. I mean I could get a 6 channel one from ebay (see link here) that would be waaay more capable than the one I've just removed for less than a tenner but that still wouldn't be controllable from my phone, laptop or desktop.

For that I need to be a little creative hence the thinking face 😉 (isn't self awareness great?)

So I decided to reuse a μController that I already had lying around the SiPy from Pycom (Specification Sheet: here). What exactly made me choose this dev board over an arduino Uno or the multitude of ESP8266 based boards I have lying around? Well it was the first thing I saw in my magic box of electronics components and more seriously it was because it is based upon the bigger-brother chip to the ESP8266 the ESP32 which has two tensilla cores, built-in Bluetooth and WiFi support whilst also being able to handle upto 5.5V on its V_{in} pin which makes it easy to hook the 3 AA batteries in the chassis to be wired directly into the board for power.

Here is the SiPy connected to its temporary development board home just after updating the firmware.

So what functionality do I need? The system at a minimum must:

  • have a WiFi access point or connect to an existing network
  • receive control signals
  • be able to send data back to the controller/client
  • not run the motors from the μC (I'm no heathen I've got some H-bridge ICs lying around somewhere so that the motors don't run off the maximum 400mA from the boards pins)

Optional extras in terms of functionality  include the ability for the client to turn the built-in LEDs on and off with a switch.

I'm gonna write it in Python because it's a nice change of pace from my usual C/C++ MCU adventures plus the PyCom ecosystem was designed for it so there is plenty of library and documentation support.

Lets load up my GUI editor of choice: Atom. I've done most of the bootstrapping already so I can write directly into the file (and anything else I link(?) (is that the correct Pythonic terminology) to) and just upload the code.

I'm using Windows for a coding project? Yeah it feels odd to me too.

In case you want to get a copy of the code I'm gonna be writing here, click the badge below, it'll take you right to the Public Github Repo with the code in:

Now for the boring bit... deciding how I should implement the control system by considering the behaviours I want it to have.

The simplest model we 'could' use would look something like this:

Where transitions from Idle to another state is triggered by a specific message.

This approach has several limitations however the most pressing is actually the inability to steer right and power the rear axle at the same time. Combining this limitation with the mechanical system in use as shown in the image below:

We can see that steering is provided by temporarily powering a DC motor in one direction or another to change the orientation of the front wheels

This combined with the sprung nature of the mechanism as shown in the below video:

The steering system springs back to neutral when the motor has no voltage applied to it meaning that a simple system wouldn't be ideally suited for the type of control I wish to implement.

So I went to sleeps, which is a rarity for me at the moment when I got up, I waited for my amazon delivery of JST plugs and some more solder. Instead of doing what a professional would and document my soldering, I just did it.

What did I solder onto this little RC car you ask? A nice H-bridge control board for two DC motors (exactly the number I have)

Now moving onto the next stage which is programming the little fecker....

I tried colour coordinating my jumper wires onto the development board... but I have a severe lack of purple.

Note to self, I was playing around with the software for a while before I noticed that I couldn't make anything happen.

from machine import Pin
from machine import Timer
from machine import PWM
import pycom


Rear Motor
yellow = Pin('P20', mode=Pin.OUT, pull=None)

green = Pin('P22', mode=Pin.OUT, pull=None)

Steering Motor
blue = Pin('G17', mode=Pin.OUT, pull=None)

purple = Pin('G16', mode=Pin.OUT, pull=None)

print("Hello World");

That's when I decided to take a closer look at the wiring...


I had not read the wiring of the DC Motor Control board correctly and had gotten things mixed up.