Designing a system where multiple cars can be controlled by keyboard via 433 MHz modules and AVR microcontrollers
To make the experience fit your profile, pick a username and tell us what interests you.
One plan I have is to implement some type of speed control. As can be seen for the demos, there is no speed control for the RC cars.
I would like to try to implement some type of incremental
speed control in the future, however it will have to be done by
joystick since I don't have any keyboards that are analog or pressure
I am planning making separate RC car projects that use different
wireless communications protocols such as Bluetooth and WiFi.
These other protocols may make it easier and simpler to control both cars
at the same time as well.
For the python script I want to create a GUI and clean up the output
of the script.
I also want to eventually work up to controlling an RC car via a web
or mobile application.
As can be seen from the demo above the cars can travel quite a bit of distance
for small antennas. If I wanted to increase the distance, making the antennas
longer and supplying the transmitter with 12V would do the trick.
The reason why the cars sometimes veer to 1 side is due to the cart wheel at the
front. An ideal substitute to the cart wheel would be ball casters, however
since I didn't have any at the time and the cart wheels came with the kit, I
decided to stick with them.
It is also noticeable how many times I over steer the cars, this is
due to a lack of speed of control. Since I am not using a joy stick
or an analog / pressure sensitive keyboard, I am not able to control
the speed therefore the car goes full speed in 1 way or the other at
the push of a button, I may fix this my implementing a joystick
controller of some sort.
Image of TX board soldered and assembled
Image of RX boards soldered and assembled
I am planning to add switches to these boards later on however at the time
I didn't have any, therefore the only way to turn them on and off was
to connect/disconnect the battery. In the case of the TX it is
powered by plugging in the FTDI232 module.
For the TX board, I decided to use indicator leds for the states and the
commands for debugging purposes.
Attaching and connecting components on the car
Image of RX boards on the cars
Image of RX boards on the car at different angle
As seen in the pictures above, the solder RX boards attached to the chassis of
with electrical tape, the 2 9V batteries are taped to together and secured at
the front of the car.
The input pins of the L298N are seen attached to the female pins of the RX
board. The white wires are where the positive of the 9V supply are attached.
Image of the TX schematic
For the TX schematic the main power source is 5V coming from USB via
the FTDI232 board.
Image of the RX schematic
For the RX I have included 9V to 5V converter, I have also included a
separate 9V for the L298N motor controller.
Ideally I would use lithium ion batteries,
however I would need many more components and features such as battery
protection and battery charging. Since I didn't have those components
on hand and didn't want to risk directly connecting lithium ion
batteries without protection I opted to use the standard 9V batteries
instead. Simpler and cheaper at the time of making this circuit.
Eventually, I will modify my schematic to include the usage of lithium
ion batteries, especially if I decide to control larger RC cars.
As can be seen by the video above, I am able to switch between both
receivers effortlessly and send the appropriate commands.
The reason why multiple LEDS are lighting up on RX side is because I
implemented the same states for turning on the motor pins as I have
done when using the varying PWM duty cycle.
As can be seen by the video, when one of the command keys is pressed the corresponding led lights up and the TX packet sequence changes to the new command. This is the same with changing receivers where only the receiver number in the sequence changes.
The sequence output is usually much faster, but for the sake of the demo it was slowed down.
** Explanation Below **
USART by itself would not be enough to send
reliable data transmissions via 433 MHz modules. Especially to 2
The solution is to send multiple bytes via USART. One byte for syncing, one
for the receiver serial number (in this case 1 or 2) and the
command (front, back, left or right).
The TX and RX AVRs both have data buffers that are used to
store the multiple bytes. When a command is chosen on the TX side,
the buffer is filled with the sync byte, serial byte and command
byte. Then sent incrementally via TX interrupt.
This is the same with the RX AVR, with the RX data buffer being
filled up incrementally with received bytes.
Initially I did have some trouble using this method, especially with
making sure the AVR on the RX would read the data in the proper
To ensure that the data received would be put in the data
buffer in the right sequence (sync, RX serial number, command), I
made it so that the RX will only fill up the data buffer if the
first thing it receives is a sync byte, else reset the RX data
buffer index to 0 and keep on waiting for the right sequence.
While debugging the RX via serial terminal, I have noticed that the
bytes being received appear in the wrong indexes. This is due to the
fact that sometimes bytes are sometimes received out of order
(i.e. command byte read first then stored or serial byte).
However, I noticed that whenever a sync byte is the first byte to be received,
every other byte is in the correct sequence. Therefore that is the
condition to ensuring a proper data transmission.
This may not be the best practice especially if I am planning on
sending more and more bytes as a packet. Receiving the sync byte
first may not guarantee that everything else will fall into sequence
however it is the best solution I have for now. Will develop it more
Also, I am planning on changing the data type sent from char to
bytes. Char was used purely for debugging purposes.
For a char data packet, s represents sync, 1 or 2 represents the
receiver number and n,f,b,l,r represents neutral, front, back,
left, and right respectively. This can be seen in the video of the initial test.
For interfacing the AVR with serial, an FTDI232 board module was used.
To manage sending commands to TX AVR via keyboard I initially tried
to use the serial terminal directly by inputting characters
in it. However, I have trouble with continuous input, when I hold
down the button, this does not register in the serial term and treats it
as 1 press, instead of a continuous press.
Therefore I decided to use python and the pyserial and pynput
modules. This allows me to not only send multiple bytes to serial
while holding a down button, but also it allows me to input keys
without having to be in the serial term window due to pynput.
Using python...Read more »
Multiple changes have been made since I last worked on this project.
I changed the microcontroller of choice from Attiny85 to
Atmega328p due to its larger number of I/O.
Transmission protocol change
I chose to use USART for this project. After some research I
realized that the 433 MHz modules are not reliable enough to send a
simple data stream such as varying duty cycles.
For more reliable data transmission it was essential not only to the
use USART but also to send multiple bytes via USART to ensure proper
transmission of data.
Using cheap DIY car kits
Also I decided to invest in cheap car kits that can be assembled
instead of trying to make everything out of cardboard.
Changing method of input
While working with the push buttons I soon realized that they are
unreliable. I even soldered a "button board" together and have still
found that the push buttons give false positives or get
stuck or break easily. Therefore I decided to change the method of input to a
computer keyboard and send various commands through serial.
Since the initial tests shows how jittery the motors are, I believe that using variable duty cycle as a signal protocol/encoder is not the best option. It may be beneficial next time to try to use a different form of encoding/signal protocol like UART, USART, ICP, SPI, Manchester and etc.
The goal of these initial tests with prototype cardboard RC car was to gauge how well my setup was regarding the wireless modules, code, circuity and etc.
Any changes that I make to any of these will be compared to this benchmark to see if performance has gotten better or worse.
After reviewing the video, it seems that there are many issues with the car including a lot on inconsistent jittering. The problem is that I am not sure if it is the code at fault or the circuity or both.
Therefore, the next step will be to take measurements when the car is connected to the transmitting attiny85 and when it is not to see when and where the jittering occurs.
Now that the receiving attiny85 can differentiate between the different duty cycles and engage the correct state. All that has to be now is to make each state a function and turn on the necessary bits for l298n motor controller.
To test whether all of this will be enough for a full fledged RC car, it is time to make a prototype RC car and see how well it runs with code and hardware at hand.
Become a member to follow this project and never miss any updates