Difference between revisions of "2021SpringTeam1"
|Line 74:||Line 74:|
Revision as of 20:54, 7 June 2021
Meet The Team Members
About The Final Project
Dominic's ROS Package
Lane guidance is a ROS Node that subscribes to three topics, “/steering”, “/throttle” and “/centroid”. 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 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
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.
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.