Category: Fausto’s Status Reports

This week we worked on some final capstone deliverables and worked on wrapping up some lose-ends in our project. Fortunately, we were able to fix steering issues we were experiencing on the second Autovot. We essentially disassembled it and put it back together carefully, tweaking parts of the motor components, switched a few parts and the drift was negligible afterwards. We have come a long way with our project and will work on demos and presentation details the rest of the week.

This week I worked closely with Joel and Jeffrey with integration. There were issues in the beginning of the week with the vehicle drifting slightly to the left, even if there was no obstacle in the way. We solved this by fine-tuning the Arduino code responsible for controlling the Autovot wheels. This included assuming the vehicle’s battery is around 8V. Additionally, we worked hard on the path planning algorithm and added a bubble of error around obstacles so that we are less likely to hit an obstacle. I also added small changes to the bluetooth communications to support messages which can send obstacle locations to the trailing car. Next week will include adding length to the course and adding more obstacles. We also worked on the final presentation and have some good videos to showcase for our presentation.

This week I worked on converting the Bluetooth communication code between Autovots into ROS code. I created new packages specific to client-side and server-side communication and tested the ROS nodes with two Jetson Nano boards. Previously I had gotten the Bluetooth connection set up and enabled communication across board but this week , I integrated the communication code into ROS in order to begin integrating communication with other components of our project (such as object detection and planning). At first, I sent arbitrary coordinates across Autovots and made sure connections were being setup properly and data was accurately being sent. Then, after debugging ROS mechanics, I created MapUpdate messages and made the server-side node a subscriber to a ‘map_update’ topic which calls a function to send map updates to the client. The client then receives the data through Bluetooth and publishes newly acquired map information to another ‘map_update’ topic.

This week, my team and I met in person to work on Jetson-to-Jetson communication. One Jetson acted as the master node and the other Jetson acted as a trailing node (aka the RC cars which will be following the lead car). We made the cars discoverable via Bluetooth and set up a pluggable Bluetooth adapter for the trailing node. We tried to setup one of the Bluetooth adapters that we ordered online (we ordered two different ones) but it did not work on the Linux system on the car, so  we will have to return that one, but now we know the other one works, so we can just order another one of the working adapter. After making the boards discoverable, we practiced by sending brief messages (like “Hello world”) and also tried sending streams of data to the lead node.

We found that a minimum of 8ms delay between sending messages was needed in order for the communication to not crash (which is perfectly fine because we will not be spamming messages one after the other in such short time frames; as of now, we plan on sending a message about every 250ms). Additionally, with our current setup we found that communication was very feasible between 3m, any further was not guaranteed to establish. As of now, the messages we send are in JSON format and we use a dictionary to encode and decode the fields we are sending. In the coming weeks I will be ensuring reliability and make the communication process more robust (by adding error-handling and add retrying if one device is not found).

This week I received the NVIDIA Jetson Nano 2GB, set it up and familiarized myself with the Jetson Nano working environment. In regards to communication, each Jetson will be discoverable to other Bluetooth devices with the naming heuristic starting with “autovot” followed by a number from 1 to 3.  After a connection is formed between the lead car and trailing cars, the lead car will be able to convey information which the other cars can utilize for localization, so they can avoid obstacles. Originally we were planning on sending full instructions on how to maneuver around obstacles but now we will convey information to trailing cars so they can develop a map with they can use to plan a path around obstacles. An action item we have is testing Bluetooth reliability while the cars are moving in order to ensure trailing cars can securely receive information from the lead car.

This week was a bit hectic for me so I did not accomplish as much as I had originally hoped. I was expecting to have tested basic Bluetooth communication between 2 different devices, but I currently just have boilerplate code setup. Fortunately, most of our hardware has arrived so next week we can all work on our physical cars. I will continue to establish Bluetooth connection between 2 devices and once we have our RC cars moving, we can think about how to send instructions from the lead car to the trailing cars.

This week, I read up on Bluetooth technology so that next week I can begin programming communication between Bluetooth devices. I mainly read a pdf I found by MIT on Bluetooth programming (https://people.csail.mit.edu/rudolph/Teaching/Articles/BTBook.pdf) which contained a lot of interesting details about how Bluetooth works and some intricacies with the technology. This pdf details how to create sockets such that data can be transmitted and includes information on piconets (which are ad hoc networks consisting of 8 devices, where one acts as a master, and the others act as slaves). One thing I didn’t know about Bluetooth is that an actively communicating Bluetooth device changes channels every 625 microseconds, so devices within a system have to sync their channel changes (I am sure Bluetooth hardware handles this but it was interesting to learn about). Next steps are: setting up basic communications between Bluetooth devices, getting a better idea of what information we want to transmit across our RC cars.

At the beginning of this week, I practiced and presented our group’s Proposal Presentation. It went well and gave our group some ideas to think about and some timeline reconsiderations we could make. The biggest critique we received was in regard to the object detection using lidar so we will most likely be drifting away from that idea to a more manageable alternative. Additionally, we realized we needed to make our goals more quantitative. I researched methods of setting up a bluetooth ad hoc network and will continue to research and settle on an implementation next week.

This week, my teammates and I worked on consolidating our ideas and goals for our project by narrowing down various different design options. After researching different forms of communication, we decided the best choice for communicating between RC cars was Bluetooth. Bluetooth works well for our purposes because it has good range, can be used for ad hoc networking and is simpler than some of the other options we were looking at (wifi). We are still deciding how much communication we want our cars to do and are exploring the idea of cars communicating at intersections for faster transportation (which car slows down, which one speeds up).  Next week, we want to finalize the hardware components we will be using for our RC cars and more clearly define communication guidelines.