Using STM32F7 to Control a Mobile Robot across WiFi

An introduction into IoT

Tim Chinenov
5 min readJan 2, 2019
The Final Rover

A field that has been growing rapidly with the further miniaturization and computational power of CPU’s is embedded hardware and electronics. This is a field I have been trying to dedicate more time to, aside from my pure software image processing and robotics projects.

As a final project for my microprocessor class, I collaborated with a friend to build a remote control car using two STM32F7-DISCO boards (DISCO). Except, unlike most remote control cars that use radio frequency (RF) communication, for our car we wanted to use a WiFi server. We were largely influenced by the Internet-of-Things trend. Standard RF RC cars are old news, and fairly easy to implement with user friendly breakout modules, such as the ones made by Xbee. In an attempt to challenge ourselves, and hopefully learn something new, we implemented the classic toy using ESP8266EX WiFi modules (Final video at the bottom).

Motor Control

The whole car can be split into roughly three subsystems; the motor controls, the WiFi communication, and the remote controller. Firstly, the motor controls are comprised of a L298n motor driver, two DC motors that were built into a tank chassis configuration, and the DISCO board itself. The DISCO board commanded the direction of the DC motors by sending an appropriate logic combination to the input of the motor driver. The speed of the DC motors were controlled by a pulse width modulated (PWM) signal. It was found that the maximum (five volt) signal spun the motors too fast, so a PWM was used to slow down the vehicle.

The wiring schematic for the motor controller subsystem.

While the above is a fairly standard set-up for any set of motors, it’s necessary to remark on why certain design elements are chosen. Primarily, the use of a motor driver is crucial for keeping the DISCO safe. Most motors require at least ten or more volts to properly run. This is an unreasonable amount for more microcontrollers to attempt to output. Twelve volts is a dangerous amount for a microcontroller to be in contact with, as most components on the DISCO board are rated for 3.3–5 volts. As a result, a motor driver is used to separate two different voltages and allow the DISCO board to still command the motors.

Remote Controller

The remote controller, the second subsystem, was a bit trickier as compared to the motor driver. The DISCO boards are shipped with an attached LCD screen. The screen has touch capabilities. Although using the touchscreen LCD made this project considerably more involved, it gave the project another aspect of modernity.

The remote controller (black chip in lower left is the WiFi module)

In order to demonstrate a simple proof of concept, we allowed the user to select from four different directions on the LCD screen. Not only does this simplify movement, but WiFi communication was simplified as well. A single direction requires one additional byte of information. More complex messages can of course be sent between the two controllers, but would require additional parsing.

The microcontroller reads information from the LCD screen by polling for a touch detection. If a touch is detected, the x and y axis locations of this point are returned. To activate a button, the coordinates of the touch must be contained within one of four predefined regions.

WiFi Communication

The ESP8266EX WiFi modules were connected to the STM32F7 through a UART line. Evidence of the popularity of the module is noted by the built-in WiFi pins on the DISCO board. The WiFi module becomes a simple hardware addition.

Flow diagram of WiFi communiation

The drivers that were used with the WiFi modules used a protocal called AT-commands. Basically, the ESP8266 takes in a string starting with “AT” and performs the command if the string corresponds to a correct option. If the command cannot be recognized or cannot be performed , ESP8266 will send a string “ERROR” to the UART. Otherwise, it will send “OK”. The receiving module prints the returned result in the form “+IPA,x,y:z”, where x represents the ID of the sender, y represents the length of the data, and z represents the actual received data.

Using the functions in the module driver, the ESP8266 is initialized in “station” mode and connected to the server with TCP protocol upon joining the Access Point. The driver used did not support initializing the module as an Access Point or setting up a server. Modifications to the driver were added to achieve this functionality.

The initialization of each WiFi module depends on the success of the other. For example, if the WiFi on the Rover does not successfully set up an Access Point when the WiFi on the controller is looking for one to join, the program will fail on the controller’s WiFi because of its failure to join the server. Therefore, a routine shown in the figure above was designed. This flow, prevented crashes and connection failures.

Results

As a demonstration of a proof of concept, the WiFi tank worked great. The remote controller was able to properly respond to touches and commands. The LCD screen on both the controller and the car properly animated buttons and displayed text (although a ‘\n’ or ‘\r’ command was printed as garbage).

While the remote controller and the tank were able to send information to each other, a considerable delay between commands and actions existed. This is visible in the video demonstration. A roughly two second lag occurs between when a button is pressed and the rover responds to a command.

While the cause of this problem has not been fully explored, the polling method of retrieving information is theorized to be the source of the lag. There are several methods of retrieving data from peripheral sources, such as interrupt requests, DMA requests, and polling. Out of these three, polling can be the most inefficient one.

Overall, this project built a platform for future development. A functional WiFi controlled robot can be adapted for interior surveillance, simple delivery tasks, or just chasing your dog around the house. I hope to develop on top of this project in the future and work out some of the current kinks.

Short demonstration of the WiFi Tank

Special Thanks

This project could not have come to fruition without the brilliant help and work of Jiawei Xu.

--

--

Tim Chinenov

A SpaceX software engineer. Im an equal opportunity critic that writes about tech and policy. instagram: @classy.tim.writes