Autonomous Robot Car with STM32🚗
Ⓒ Copyright Tianyi Liu 2019-2020, All Rights Reserved.
Latest Update: 12:29 AM July 1st, 2020 CST
This repo contains the source code developed for EIE3105, delivered by Dr. Lawrence Cheung and Dr. K.H. Loo, Dept of EIE, HKPU.
💥If you use or partially use this repo, you shall formally - in report or presentation - acknowledge this repo.
EIE3105 is an integrated hardware-software project that covers from the soldering to MCU programming. It uses PID controllor as the baseline, requiring students to implement control algorithms to accomplish different tasks with ta robot car autonomously.
✔️Simply clone this repo through
git clone https://github.com/evanliuty/eie3105
✔️Open your IDE, build and upload to you MCU.
source contains all the source files
img contains the images
doc contains the documents and deliverables
test_quiz contains previous quiz and test USE AT YOUR OWN RISK!
The main body of the robot car will be distributed in the class. You will need your own STM32F103RBT6 and corresponding cables.
For IDE selection, I used the Keil µVision with Windows 10 x64. You can also consider STM32CubeMX which can be run with macOS.
⭐️### ARM_USART
This is a quite useful program for you to debug your program. You can send certain character or value through USART and connect the corresponding USART to your STM32 to display the values using TeraTerm.
Robot Car Send Information
Robot Car USART1 ---Ext. Cable---> STM32 USART1/3 ---Int. Program---> STM32 USART2 ---USB Cable---> TeraTerm
Robot Car Receive Information
TeraTerm ---USB Cable---> STM32 USART2 ---Int. Program---> STM32 USART1/3 ---Ext. Cable---> Robot Car USART1
Perform line tracking and track changes without human intervention.
I considered the robot car on the track when the left boundary of the black line lies between the 3rd and 4th photo-resistor, and the right boundary lies between the 5th and 6th photo-resistor.
Therefore, this provides us with two options: Follow the left boundary or follow the right boundary. It also helps the robot car to perform track changing.
P Control
Hitting 3 balls autonomously with the location information provided by WiFi station.
The robot car will acquire and update the locations repeatedly from the WiFi station with a timer. After every timer overflow event, it will listen until a : is received, which marks the starting point a data frame. Then, it stores all characters except for \r and \n. When an M (from CMD) is received, the timer is disabled and the program process the received information to update the corresponding locations. After the processing, the timer is re-enabled and wait for the next overflow event. However, such setting is not rigorous and also not the correct way to use the data frame. At the WiFi station, there are a few options that can be encoded in the data frame to control the robot car. Due to time limitation, we did not implement such function. A cherry-picked decoding scheme decribed above should work for demos.
Instead of using the absolute differences in x and y axes as PID error, I defined two vectors, a path vector, and a velocity vector. Moreover, I used a one-cap design that requires only one marker to locate the car and calculate its heading. The path vector is calculated as the difference between the location of the ball and the location of the car (cap). The velocity vector is calculated using two consecutive measurements of the robot car location.
PI Control
We can see from the above image that when the distance becomes smaller, a same disturbance will create a larger error (in terms of degree). Therefore, using the same weighting parameters may not be a wise choice. Instead, the proportional weighting factor is linearly decreased with the decrement of distance, while integral remains constant.
Two robot cars hit the ball in turns, from one green region to the opposite green region, again, autonomously.
Same as Demo 3
Same as Demo 3
PI Control
Similiar to Demo 3, in Demo 4, both proportional and integral weighting factors are linearly mapped.
A major difference between Demo 3 and Demo 4 is the locations of the balls are not fixed. Consequently, using the same strategy to hit the ball cannot guarantee the ball entering the opposite green region. A compensation scheme is designed to reduce this effect, or it can be called a hitting-target design, in contrast to hitting-ball.
First, an offset is defined by the distance the ball entering the green region (~the distance the ball needs to travel to the opposite green region). An extra distance is defined by the y-axis difference (~final hitting angle). Then, the car will actually hit the target defined by two previous steps, instead of hitting the ball itself.
Finally, the speed (PWM) is given by:
This folder contains all lab files.
The lab sheet can be found here: Sem1 Sem2
👍 Thanks Mr. Bowen YANG for the very helpful discussions and suggestions during my implementation of this project.
💯 Try to implement your own control scheme first. This is a good and interesting class.
❗ This repo is for your reference only, directly copy or modify without proper acknowledgment will result in plagiarism.
📝 A formal version, i.e., the final report, of this README file can be found here.
😎 Most importantly, enjoy the class!