My attempt at making a rudimentary RC car with a couple of attiny-85 and some 433Mhz Modules.
Since the initial tests shows how jittery the motors are. It is time to take a look and see what is going on.
To test whether or not it is the fault of the code, I ran the RC car as it was connected to the pwm generating atttiny85.
A voltmeter was attached to the input pin of the receiving pin and ground and the measurement was the frequency.
This was also done when the modules were used (not connected).
Here are the results:
However when the modules get involved that is when the trouble begins.
The frequency jumps all over the place, therefore I will assume that some sort of unity gain buffer or amplifier will be needed.
I also 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.
Here I programed the receiving attiny85 to sample the incoming pwm signal when it was high. When the signal becomes high, a ctc counter starts and counts the amount of the time the signal has been high for, thus giving our duty cycle.
With this, at specific duty cycles, a certain state will turn on. With 4 different duty cycles that could be make from the transmitter attiny85, there were 4 different states that could be turned on from the receiver side.
Here is as demo of it:
Since the state machine was working, that means the duty cycle measuring technique works, so for now on will use this method of signal encoding.
For my first time trying to establish wireless communication, I thought about sending varying duty cycles of pwm, to the attiny 85.
One attiny85 would have buttons that would change the duty cycle of a pwm signal. This pwm signal is then inputted into the ADC of the attiny85 where is it then sampled and the voltage level is read.
Since different duty cycles of pwm, result in different voltage levels I thought the ADC wouldn't have a problem reading the voltage of the pwm.
However, this did not work not, instead the leds started blinking at certain rates depending of the duty cycle that was created (button pressed). It seemed that the ADC wasn't working with the pwm signal at all.
After some time, I found out that reducing the pwm frequency and getting the receiving attiny85 to measure the duty cycle of the pwm instead of treating it like a voltage value would be a better way of sending data.