Control and Sensing
In part 1 of this two-part article series, Pedro laid the groundwork for his autopiloted four-wheeled robot project by exploring the concept of speed estimation and speed control. In part 2, he dives into the actual building of the robot. The project provides insight to the control and sensing functions of autonomous electrical vehicles.
The previous article in this series explained all the digital signal processing techniques and mathematical approaches needed to reliably estimate speed using accelerometer data. Also, a PID control approach to control speed was presented. In another words, we showed the “real-world path” to go from raw accelerometer data to speed estimation and a way for controlling speed, considering a real-world inertial sensor handling overview.
Now it’s time to combine all these techniques and approaches to an interesting project: an autopilot robot. The purpose of this project is to practice all the concepts learned in previous article and take the first step in autonomous electrical vehicles control and sensing, what will open the door to an endless journey through electrical vehicles engineering evolution. This project is completely open-source. Its source-code is hosted in this Github repository.
As pre-requirements, this article considers that your BeagleBone Blue is fully operational. If you’re building along with me, please don’t proceed until everything’s ok in your BeagleBone Blue.
1) Debian Linux is installed and running correctly.
2) BeagleBone Blue has working Wi-Fi network connection.
3) You have no issues to SSH access the board over your local network.
This project consists of a 4-wheeled (electrical) autopilot robot, where its speed is estimated based on native BeagleBone Blue’s accelerometer samples and speed control is done by a software PID control. Everything implemented in C language programming.
In a general way, this robot is able to maintain its speed even in non-conventional situations, such as:
• Robot mass increase/loss during its movement
• Pavement condition changes
• Motor performance decrease
In another words, the speed will be controlled just like there’s someone’s foot on the robot’s gas pedal to keep robot speed constant. Looking at the big picture of this project, this concept can be really relevant for real electric car development—including the autonomous cars. With that in mind, this effort shouldn’t be approached only as a DIY project only, but as a project that open a door to an endless journey through electrical vehicles engineering evolution.
The first thing to do is assembly the robot. This is relatively straightforward. First, assemble the robot’s chassis, including all the motors. Next, installed the BeagleBone Blue board in the chassis. Make sure to give easy access to 12 V battery charger connector. Then, connect of motors of chassis in BeagleBone board, using four 2-wire JST- ZH (1.5 mm pitch) connectors and wires. Finally, connect the 12 VDC (3 A or more) LiPo Battery to BeagleBone board battery socket. That’s it! After assembling the robot, it should look like shown in Figure 1.
The whole project software comprises of the following modules:
PIDControl.c and PIDControl.h: source-code and header file of PID control (used for speed control);
SpeedCalcByAcc.c and SpeedCalcByAcc.h: source-code and header file of speed calculation/estimation based on accelerometer data. This contains all DSP steps described on first part of this article’s series;
main.c and GeneralProjectParams.h: source-code and header file of project, including its main functioning. Also, main.c contains all MQTT project support (connection, subscribed messages handling and publish message routines);
compile_and_run.sh: shell script for compile and run project;
robotics.mk and Makefile: project makefile;
To achieve maximum performance and full Robotics Cape API compatibility, the project software is written in C programming language. To compile it, the native GCC in BeagleBone Blue’s Debian distribution is used. The compilation time isn’t abusive and cross-compiling is not required. Another important point about this project’s software is that all relevant data—current speed, speed setpoint and acceleration measures—are exported to files in tmp folder. The folder /tmp is mapped in RAM space, so there’s no risk of damaging flash by excessive read-write cycles.
In the particular case of this project, there are some considerations concerning PID speed control. All inputs to PID function/block are normalized. That means that, before PID being used by PID functions, setpoint speed and process variable (current speed) are divided by maximum speed allowed by robot (this information is empirically determined). Once all inputs to the PID function are normalized, the PID output will be normalized too. The output PID speed control value is directly applied to the motors as duty cycle.
TESTING THE ROBOT
Assuming you’re having no issues in SSH communication between your computer and BeagleBone Blue, it’s now time to test the robot, using the following steps.
First of all, you must give execution privilege to the compilation and running script. It can be made typing the follow command:
sudo chmod +x compile_and_run.sh
Finally, it’s time to put this robot to work. To do this, type this command:
Notice that root privilege is required for compiling and execution. It’s needed due to required access by Robotics Cape API (any use of this API requires root privilege).
To achieve the results shown in Figure 2, the gains were empirical adjusted as follow:
KP (proportional gain) = 2.5
KI (integral gain) = 1.0
KD (derivative gain) = 0.0
Figure 2 shows speed control action. In blue is represented the speed setpoint value (0.1 km/h) and in red is represented the speed after PID control. Notice that the movement (command to move was received) actually start on 5 seconds mark. Based on graph shown in Figure 2, it’s safe to infer that PID control is working well, smooth and without overshoot. Although, if a faster or more precise PID action is needed, a nice place to start is by the tips in “Speed Control – PID” section in Part 1 of this article series (Circuit Cellar 339, October 2108).
The auto-pilot mode (as setpoint configuration) is fully configured and monitored by MQTT messages. That means it can be configured from anywhere in the world. All the MQTT messages involved in this project are described in Table 1.
Despite being very simple, the MQTT messages for control and monitor autopilot are enough for this project. The messages are not so large—they don’t carry a lot of bytes in the payload—so it’s not a problem to use MQTT with some highly restriction traffic network, such as mobile Internet connection. This opens the opportunity for some interesting evolution for this project using a mobile Internet connection.
As future improvements, one of the most important tasks is to implement is the auto-adjustment of PID proportional, integral and derivative gains. In the particular case of this project, empirical adjustment is enough, but that may be not acceptable for a real electric vehicle project.
Putting this in a telemetry and IoT context, another suggestion for future improvement is add more telemetry information to the MQTT messages. This would enable not only pure monitoring, but the opportunity to make remote analysis of the vehicle’s performance. Also, as long as a complete set of vehicle data is available to cloud platforms, it’s possible to add Artificial Intelligence resources. This opens the possibility for making the vehicle’s performance dynamically adjusted—and constantly improved. For autonomous vehicles development, the usage of cloud functionalities can actually increase vehicle’s security and immunity to hacker attacks, as long as car software and software behavior can be constantly updated.
In this article, we explained how to go from accelerometer raw samples to a reliable speed estimation/calculation in a practical auto-pilot project using BeagleBone Blue board. Despite being mathematically simple to obtain, speed estimation by accelerometer data in the practical world requires a lot of non-intuitive techniques and DSP approaches. All the math and DSP work used are “laboratory” kinds of DSP handling for embedded systems development. It deals with using reliable sensing to accurately measure the outside world of embedded systems. Using PID control to control the speed is a critical part of robot’s auto-pilot functionality.
Github repository: https://github.com/phfbertoleti/AutoPilot_Project
Software used in this project:
Operating System: Debian Linux
Programming language: C
Sensors and drivers API: Robotics Cape
Additional libraries: Paho MQTT
Freescale/NXP, “Application Note: AN3397 – Implementing Positioning Algorithms Using Accelerometers”, 2007
Eclipse Paho MQTT official website
Robotics Cape API (Strawson Design)
James Stewart, “Calculus: Early Transcendentals (6th Edition)”, Cengage Learning, 2006
David Halliday. Robert Resnick and Jearl Walker, “Fundamentals of Physics (10th edition)”, Wiley, 2013.
Beagleboard.org | www.beagleboard.org
Eclipse.org | www.eclipse.org
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • NOVEMBER 2018 #340 – Get a PDF of the issueSponsor this Article