For the design of the car I went with a tank style turning system, that way I could easily control the car using 4 buttons.
I have tried various protocols and methods for wireless communication. I tried using ADC with almost no success, varying PWM duty cycles with limited success.
The protocol that works at this moment is using USART, but since wireless transmission via cheap modules is not reliable. I needed to send multiple bytes at a time via USART to ensure proper reception.
This also allows me to switch between multiple receivers by specifying a serial number for each and switching between them by sending the serial number byte of the receiver that I want to contact.
Also instead of using a button board, I opted to use a computer keyboard and send commands to TX AVR via serial.
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 sensitive.
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.
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.
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, 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 different receivers.
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 sequence.
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 later on.
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.
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.