Microcontroller

Whole driver of the robot is handled by ATmega8 with internal 8MHz oscilator. It is probably the most popular and one of the cheapest uC today. In my opinion, microcontrollers like ATmega8 are good enough for simple one-task drivers, but using it for multi-task applications, even if possible, is very awkward.

​

In project, two modules were needed:

• software PWM signals (ATmega8 has only two 16-bit PWMs)

• wifi communication

​

Each of them is easy to implement separately, but major assumption was to achieve good stability of servo-motors (good quality of software PWMs). The problem is that in microcontroller we have only one thread (main function). If PWM driver and handling communication would be on the same thread, WiFi could took too much processor's time and affect motors. First attempt to solve the problem was to give PWM driver higher priority than communication and implement generating signals in interrupts. Unfortunately, 8MHz is too little to handle controlling servos on software timer. ATmega8 could generate interrupt every 50us with still stable working (not affecting communication too much). PWM signal for servo-motors has period of 20ms, where pulse width vary from 0.7ms to 2.2ms (total 1.5ms). It gives us:

 

software_timer_freq = 1s / timer_interrupt_period = 1s / 50us = 20000Hz

 

Our software timer will increment 20000 times per second. We need to overflow it with frequence of 50Hz (PWM frequence):

 

20000Hz / 50Hz = 400

 

Counter should be reset every 400 ticks. That means, software PWM has 0.05ms resolution (20ms = 400 ticks).

 

400 * (1.5ms / 20ms) = 30

180* / 30 = 6*

 

Servo motor driver has 6 degrees resolution. This is terrible resolution for robot. It is very stable and communication do not affect motors, but they can't move smoothly. Solution will be explained in software section.

​

Software

Software is divided into four layers:

• main program

  • ESP module

    • USART (WiFi) communication

  • Software PWM

​

USART (WiFi) module

We can say that receiving data from USART is equal to receiving raw data from network sockets that ESP packed into special frames. USART module is responsible just for receiving this raw data into ringbuffer, without any process steps. It is necessary for performing fast, non-blocking data receiving in next layer.

​

ESP module

Here, data from USART module is parsed. Because we have already data in memory, we can check if whole frame has been received without waiting for bytes (and blocking thread). This module gives us decoded data that has been sent from the controller. It has also timeout parameter that allows optimize handling packets. If new frame has been detected, module will wait for all data to be received or time has passed.

​

Software PWM

This is very simple module that generates PWM signal with use of one 16-bit timer. Every time when servoUpdate() function is called, PWM output pins are updated. It allows also to set destination angular position of each motor and uses equation based on simple discrete transmitance to reach smooth move characteristics.

​

Main program

When we have all above modules, main function becomes pretty simple, but uses smart trick to create two virtual threads and maximize performance. Controlling servo motors with PWM needs 50Hz signal with impulse lasting up to 1.5ms. That means, high signal lasts maximum 1.5ms and low signal lasts at least 20ms-1.5ms=18.5ms. 18.5ms of generating... nothing. I decided to use the time while PWM module has nothing to do, to handle WiFi packets. For PWM module important is only the moment when signal becomes high or low. To reach the best quality of signal, PWM module takes all the processor's power for a 5ms to generate 0.7-1.5ms high signal. After this time, for next 15ms signal is low and program is switched to handle wifi packets.