Difference between revisions of "2021SpringTeam1"
|Line 133:||Line 133:|
==Behind The Scenes (BTS)==
==Behind The Scenes (BTS)==
[[File:Pcbtest.mp4|500px|thumb||Testing our Power and Signal Distribution PCB!!]]
[[File:Ledboardtestagain.mp4|500px|thumb||testing FANCY LED Board!]]
[[File:Centroidfailure.mp4|500px|thumb||centroid plotting went wrong :(]]
[[File:POWER_PACK_BACKUP.jpg|500px|thumb||We used to have this DIY cute power pack when our jetson messed up]]
[[File:FIRST_VERY_OLD_VERSION.png|500px|thumb||our old car design that we crashed and broke in half :') ]]
Revision as of 03:20, 9 June 2021
Meet The Team Members
About The Final Project
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
TODO - George
BLDC HallEffect Sensor Breakout
TODO - George
Dominic's ROS Package
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.
LED Board STM32 Firmware
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.
Recap of Achievements!
<iframe width="560" height="315" src="https://www.youtube.com/embed/nfy5VQqqMNo" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
Challenges & Lessons
Thanks Dominic, Haoru, and the best professor JACK! And other teams for the great quarter!! :)