- 1 Meet The Team Members
- 2 About The Final Project
- 3 Inventories
- 4 Hardware
- 5 Software/Firmware
- 6 Mechanical Design
- 7 Some Recaps of Achievements!!
- 8 Acknowledgements
- 9 Behind The Scenes (BTS)
Meet The Team Members
- George Troulis - ECE (Senior)
- Arthur Dassier - CSE (Master - Exchange student)
- Dev Gulati - MAE (Senior)
- Muhammad Arsani - ECE (Freshmen)
About The Final Project
Our aim for the final project is to build a more reliable EMO circuit to replace the switch-and-relay system we had initially. On top of that, we also implemented a real-time PID control on our app, which allows use to tune the PID whilst navigating the car autonomously.
|Item||Link||Cost||Why we bought it|
|DC-DC Converter with Screen||Amazon||$15.98||It allows us to monitor how much current the Jetson is taking it. We initially had issues with the Jetson suddenly turning off multiple times when we go full throttle. This fixed the issue.|
|ESP32||Amazon||$10.99||This is for our final project, replacing the PWM board and for our efficient EMO Circuit!|
Some custom PCBs were designed to facilitate certain requirements of our project, such as power/signal distribution, or gaming-PC-like RGB LED aesthetics.
Power and Signal Distribution PCB
The Power and Signal Distribution (PSD) PCB facilitates the distribution of power and various sensor/control signals. It uses JST-XH connectors because they are resistant to vibrations, and the 2.54 mm pitch allows them to be omitted and replaced with male headers for quicker prototyping with DuPont jumper cables.
5V Power Rail
The power rail has no input/output; all power/GND connections are shared. One of the four JST-XH connectors brings 5V from the DC/DC converter, and another distributes it to the Jetson.
The other two were initially supposed to power the LEDBoard and the IMU, but the LEDBoard has its own dedicated 3.7 LiPo battery, and the IMU was not included in the final project.
One of the four JST-XH connectors receives the SDA/SCK I2C Master signals from the Jetson nano, and the other three connectors distribute those signals to other devices
Initially, we were to connect the ESP32 and the IMU to the Jetson this way, but the ESP32 receives Power/Data from the Jetson via USB 5V/Serial, and the IMU was not included in the final project
PWM Signal Breakout
There are two PWM wires: Throttle, and Steering. Each PWM wire has 3 connections: GND, Power, and Signal. To avoid making a mess of connecting 6 wires to the ESP32, the PCB simplifies the connections by providing two 3-pin male headers for the PWM cables, and a single 2-pin male header that connects to the ESP32, and routes the signals appropriately between the ESP32 and PWM cables.
For the two 3-pin male headers that connect to the PWM cables:
- The 2 Power signals are connected to each other (but NOT to anything else, as the ESC provides 6V to its power pin, which is used to power the Servo as well)
- The 2 GND Signals are connected to each other, and the shared GND
- The 2 PWM-signals are routed to a single 2-pin male header, which the ESP32 connects to with DuPont jumper cables. The ESP32 thus only needs to provide 2 wires to control the Servo/Throttle
BLDC HallEffect Sensor Breakout
TODO - George
Lane guidance is a ROS Node that subscribes to three topics
After initiating the node, we instantiate an mqtt object, and import the paho-mqtt library which provides a client class that enables applications to connect to a MQTT broker to publish messages, subscribe to topics, and receive published messages.
There are two important callback functions defined in the mqtt_client:
- on_connect is called after the mqtt client successful connection, it subscribes to three paho-mqtt topics, “/app/pid/kp”, “/app/pid/ki” and “/app/pid/kd” where the PID’s values are published.
- on_message is called every time a message is published in those topics, we change the attributes KP, KI or KD of the PIDController object according to which topic the message was published on.
We’re using the serial module which encapsulates the access for the serial port, to connect to the ESP32:
- The port : /dev/ttyUSB0
- The baudrate : 500,000 (500 kbps)
Our format to send messages to the ESP32 consist of a string with one single letter, s of steering and t for throttle, followed by an underscore and the desired value.
Let’s say that we want to send 1 as throttle value, the message that will be sent to the ESP32 will be : “ t_1 ”
ESP32_Client is a ROS Node that subscribes to two topics, “/steering” and “/throttle”. We instantiate the ESP32_Mjolnir class described above globally in the file, we use the self explanatory function steering_callback and throttle_callback to send the steering and throttle values that we receive in both “/steering” and “/throttle” topics. One thing to note is that we scale down the throttle value before sending it to the ESP32.
In this class we are just defining attributes that we will use in the lane_guidance file described below. The most relevant attributes are kp, ki, kd, limMin and limMax. LimMin and LimMax are set at -1 and 1 as the float value for controlling throttle and steering shall always be between these two.
tickPID is the function in which we compute the PID using the attributes of the PIDController object:
The set point is the centroid that we receive in the “/centroid” topic.
The process value is the width of the camera frame. Width represents the width of the track, so we divide it by 2 to represent the position we want to be located at, where 0 is the left of the track and width is the right.
The output is the steering value that we publish in the “/steering” topic. It is a float value from -1 to 1.
The error value is how far the centroid is way off the center, which is the line we want to follow.
Error = Centroid – (width / 2)
Lane guidance is a ROS Node that subscribes to one topic “/centroid”, and publish in two topics “/steering” and “/throttle”. After initiating the node we instantiate an mqtt object, an import of the paho-mqtt library which provides a client class which enables applications to connect to an MQTT broker to publish messages, and to subscribe to topics and receive published messages.
There is two important callback function defined for the mqtt_client: on_connect is called after the mqtt client successful connection, it subscribes to three paho-mqtt topics, “/app/pid/kp”, “/app/pid/ki” and “/app/pid/kd” where the PID’s values are published. on_message is called every time a message is published in those topics, we change the attributes KP, KI or KD of the PIDController object according to which topic the message was published on.
The App was designed using MIT AppInventor. TODO Project Link. It uses MQTT to communicate with both the Jetson and Mjölnir (The ESP32). The buttons and sliders behave as follows:
Force MQTT Reconnect: Forces the MQTT client on the phone to connect to the MQTT broker at the specified domain above the button (Default is the car, ucsdrobocar-148-77)
Emergency Stop: Publishes message 'ESTOP' on topic 'app/estop'
Enable: Publishes message 'RESUME' on topic 'app/resume'
PID Sliders: Publish their value on topics 'app/pid/kX', where X is p, i, or d respectively. When a slider value is modified, the value is sent after 200ms instead of immediately to avoid MQTT congestion
Our aim for the base plate design is to provide easy access between the connections on the chassis and the jetson whilst maintaining aesthetics. The rounded rectangular holes achieve this goal. Unlike most teams in the previous quarter, we decided to not use a long base plate, so that we can have a very minimalistic and compact design, such that the car is not that tall mechanically, hence improving the racing ability.
Referring to Version 1 of our base plate in Figure 1, we realized that the sharp corners of the X's causes our base plate to snap in half when we collide into a chair. It literally split in half exactly at those X's, as if someone was laser cutting it that way.
Therefore, we resorted to Version 2, replacing the X's with rounded corners rectangles. We did not crash the car to test if this testifies our hypothesis regarding the problems caused by the X's, but this new design is certainly more rigid; we had very minor accidents, and it holds perfectly.
A camera mount was designed and 3D-printed using acrylic. We designed two versions of the camera mount. The first design was tall and bulky, as shown in figure 1 below. It was initially made tall to ensure that the camera would capture a wide field of view and see further down the track. A bolt-and-nut mechanism was used to lock the camera enclosure while giving flexibility to try out different camera angles and find the most optimal. During the final project, a second version (see Figure 2) was created that was more compact by reducing the amount of material used while still providing flexibility to adjust the camera angles.
Some Recaps of Achievements!!
Thanks Dominic, Haoru, and the best professor JACK! And other teams for the great quarter!! :)