Author image

RC Car


Difficulty:
3/5


This is the implementation of a Radio Controlled (RC) car scaled 1-16. When talking about “implementation” I refer to the electromechanical assembly of the parts required, their wiring and microcontroller programming.

The goal is to move the car around telepathically (no just kidding) using a transmitter i.e. remotely controlling it via radio frequency signal waves and technology used to decode and encode those signals on the receive and transmitter ends respectively.

Hardware & Software used:

  • the popular programmable MSP430 microcontroller chip (MCU) from Texas Instruments
  • HC-06 Bluetooth module
  • L293D(ne) H-bridge chip
  • IAR Embedded Workbench 7 for Windows, student license for programming
  • Windows 8.1 x86_64
  • Tera Term and Putty for IO serial comms via UART interface.

You will have to find the datasheets for all those circuits on your own though. A trivial search on the internet will suffice.

Assembling an RC car.. What does that entail? In a basic sense I would say, “Give me the chassis, the wheels and the motors”. And that's pretty much it. I went ahead a bought a toy car for ~15$ disemboweled it (excuse my french) and then created my own wiring circuit using a microcontroller, an h-bridge chip, a bluetooth module and a few wires. I figured that the bluetooth module would make an excellent short distance receiver, of course I can replace that with an radio receiver that works long distance but in this case of this small car, I won't even be able to see exactly where it's headed if it escapes say a 50m distance.

In that case I'm sorry I should have named the project “Bluetooth Car” but it's the exact same procedure (as we shall explore in another project).

Then I found myself 2 motors plugged them in all the right places, made the connections and done. Yeah, you heard correctly 2 not 4 motors, we had to cut off our expenses to save on practicality.. In all seriousness though there was no need for 4 motors at all. The back-wheels motor moves the vehicle forward and backward and the forward motor turns the 2 front wheels left and right, just like in a real non-4WD car.

Now how to make it tick.. I have to program the MSP430 to respond the way I want it to given certain input signals.

To cut a long story short, pressing certain buttons on my computer's keyboard transmits certain signals via bluetooth module to the bluetooth receiver on the car. The latter unit forwards them to the MSP430 which decodes them and sends the control pulses to the h-bridge chip. The H-Bridge which in turn drives the currents powering the RC Car's 4 motors.

H-Bridge stands for Half Bridge. An electrical bridge is a 4 terminal network powered by a power supply and its driving a load. Now the half bridge does the same but it has the special ability of driving 2 motors (aka “loads”) together.

Here's the block diagram taken from the datasheet and sketched it to include connections and the motors (i.e. coils).

motors block diagram

And here is the complete wiring diagram with pinouts for the entire assembly:

wiring diagram

There's a little bit of it in Greek.
If you pay close attention there are actually 3 power sources:

  1. The upper left part indicates the power supply for the motors, which consists of x2 9V, 330mAh batteries in parallel (to increase our current demands).
  2. The upper right part contains the power supply for the MSP430 which requires ~from 2.8V to 3.5V, for which I used 2 1.6V batteries connected in series (to double the voltage). Measuring with the multimeter the combined voltage was about 3.3V which is great.
  3. The third one is upwards of the HC-06 module. As we see it is a ~5.2 V needed to power the L293D H-Bridge IC. I used 3 1.6V batteries here in series connecting the Vcc2 terminal input of the IC.

You might think there was a superfluous use of power here right? Not really, but I could optimize things to split the 5.2 V and with a voltage divider (picking the right resistors) supply some of that current to the low-power MSP430 device. I could do that, but it's beyond the recommended input voltage rating. I don't think it would burn up so easily, but with prolonged use it could damage the unit.

The toy motors used are really toy-level quality so they may glitch and act erratically spontaneously. I didn't face any significant problems with them though. But you can use your own Pro-motors. However, especially with low-quality motors phenomenons such as back-voltage may be triggered. This entails the generation of anti-electromotive force in our circuit which runs against our primary power direction and also negatively affects our circuits.

Which is why I've used a capacitor with a 56kO pull-up resistor for the reset signal of the MSP430. This is not necessary per-se but in my opinion it is highly recommended. First off the RST terminal is active low (indicative by the little horizontal dash over it). The capacitor is a bypass capacitor required for suppressing high-frequency noise (discarding it to the ground). Without it the MSP430 would Brownout reset on its own, as it happened to me twice. The resistor is used to delay the amount of time the RST pin needs to reset the MSP430 circuit. According to its datasheet this delay is necessary for the MCU to reset its internal state, otherwise some internal registers were in danger of not being set to their default values.

The down right part indicates a common ground for all our electrical - a unified voltage reference point - important.

M1 is Motor1 for the back wheels.
M2 is Motor1 for the front wheels.

When researching the code, refer to the table below to trace which terminals are connected to the motors and what action each one performs.

Motor1 - Back axis wheels:

P1.6 (EN1.2) P1.5 P1.3 Action
0 X X STOP (free stop motor due to friction)
1 1 1 ACTIVE STOP
1 0 0 ACTIVE STOP
1 1 0 FORWARD MOVEMENT
1 0 1 REVERSE MOVEMENT

Motor2 - Front axis wheels:

P1.0 (EN3.4) P1.7 P1.4 Action
0 X X STOP
1 1 1 ACTIVE STOP
1 0 0 ACTIVE STOP
1 1 0 Turn Right
1 0 1 Turn Left

I've used a serial COMMs program called Tera Term (Putty also works) which connects to a USB bluetooth module on the PC (which you can get anywhere) transmits the commands to the Car's Bluetooth module (HC-06) and finally to the MSP430.

The MSP430 and the Bluetooth module interface connection:

uart communication

MSP430 Pins HC-06 Pins
P1.1 TXD (transmit end)
P1.2 RXD (receive end)

P1.1 is the UART receive pin. Meaning that it receives data from the Bluetooth HC-06 module.
P1.2 is the UART transmit pin. It transmits data towards the Bluetooth (in theory as that will never happen in our case).
It's worth noting that the HC-06 unit can only act as a slave device (in contrast to say HC-05 which can be both Master & Slave).

The last piece of the puzzle, I ask you, is how do we produce those “commands”. Take a minute to think about it then read on.

Well it couldn't have been easier, I just press a keyboard button on Tera Term, then press Enter and it is sent! For instance the 'r' key means that the forward wheels need to turn right. It is straightforward in the code file RC Car.c.

Finally the RC car looks like this:

rc car 1

rc car 2