Fausto’s Status Report [05/08/2021]

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.

Fausto’s Status Report [05/01/2021]

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.

Team Status Report [05/01/2021]

This week our team worked together in the Hammerschlag Hall in order to integrate our subcomponents.  We had to first fix a drift in our vehicle mechanics when driving. We spent the first half of the week working on solutions and after fine tuning the Arduino code for controlling the wheel motors we were able to minimize the car’s drift to a negligible amount. This also included tuning the car for a voltage of around 8V.

Afterwards, we focused on path planning. This consisted of ensuring that our map could easily store obstacles in order for the vehicle to evade them when it approaches it. When an object is detected, we store the coordinates in a grid and use an a* path planning algorithm in order to evade the obstacles.

Here is a video of our Autovot evading bottles in a 5 meter track.

https://photos.google.com/share/AF1QipM4vXyGAEwav4UiZpMWxbm0fC-az3GwzySdDtf6znFCiBmR_U6mEHh3kuwSQ96Cbw/photo/AF1QipNYxix8M9KpOIC2CBKNjz5KXW2yVcWYmDC4Es_f?key=aWlpZkhjcEhRMjR4VUEzbGlaQ0hhVXpJY0paTmR3

Additionally, we spent sometime in the end of the week working on the final presentation. We are almost done with it but prioritized pushing the progress of our project and are at a very good place. Next week will include increasing the track length and adding more obstacles and testing to see how our Autovot reacts to that. Finally, we will have to test how well the following Autovot evades the obstacles using the lead car’s messages.

Team Status Report [4/24/21]

This week our team focused on preparing our subcomponents so we could integrate them together properly. In regards to the vehicle mechanics, we switched from standard wheels to mecum wheels, which allows for the vehicle to more easily maneuver around the course and maintain more accurate localization information. Additionally, accommodations to the body of the car were made in order to support the camera being mounted on the vehicle. This week we ran into issues with running our object detection program on the Nvidia Jetson. We ran into an issue where the network we were using was too big and consuming too much power and memory, so the frame rate was too low for our usage. So we moved to a Tensor RT base for the neural network inference and switched to mobile net-v1 since it was too difficult getting v2 to load. This solved the issue and we are now steadily hitting around 30 FPS and no longer run into resource issues. Finally, throughout the week we focused on migrating our code into ROS and looking forward to next week, we will fully integrate our systems.

Fausto’s Status Update [04/24/2021]

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.

Fausto’s Status Update [04/10/2021]

This week I improved the Bluetooth communication protocol by constantly looking for connection between Autovots. Now, if one device is not found immediately (for example, if the device is out of range) then when the device becomes discovered, connection will be formed. Additionally, I performed some stress tests and found that once Bluetooth connection was formed, it was not easily broken (even if we moved far away or moved behind walls). For the purposes of our project, we are comfortable knowing that the Bluetooth connection will stay connected throughout the drive on the track (since the connection would only be broken when distances are more than twice the distance of our track length). Also, connection is still formed between moving Autovots within a range of 4 meters, comfortably (in open spaces).

Additionally, I have begun researching ROS in depth and was performing tutorials and hope to integrate communication within ROS soon. I have also developed a rough sketch and description of what our ROS architecture will look like (note this is the first sketch so it is brief and is subject to modification).

Team Status Report for 04/03/2021

This week our team made great progress on individual components for our project. A lot of our hardware parts arrived so we were able to do a lot of hands-on work with them; time was devoted to installing the proper drivers and setting up the new hardware parts. Soon enough we will enter the integration stage of our project, but next week, we will be tying up loose ends in the specific project areas we worked on (detection, mechanics, communication).

In regards to our detection system for our lead car, we experimented with the intel RealSense camera (previously we have been testing our detection algorithm using OpenCV and our laptop camera), We were able to extract RGB values and use them to classify objects detected. Additionally, we tested robustness and how moving the camera around would affect the image feed + process speed of MobileNet v2 and the observed behavior is meeting our expectations.

In regards to our communication architecture, we were pleased to find that after obtaining Bluetooth adapters which integrated with the Jetson Nanos successfully, connection was established easily. We found that stable connection is maintained within 3m and that when a connection was formed it did not break (we need to ensure this is true when both Jetsons are moving in the upcoming week with further tests). We found useful information about the Bluetooth connection and will work on making the Bluetooth software between boards as robust as possible.

In regards to the vehicle mechanics, we received new batteries and UEBC device to power Jetson and we are pleased that they last more than an hour under a stress test ! Additionally, a new CAD design was made to accommodate the new hardware components. The IMU component we are using does give us an sub-optimal sense of displacement and localization so we will be adding an optical wheel encoder for the 2 rear wheels so that our vehicle localization will improve. The drive system is almost done, along with refined code for the vehicle (the serial communication now works such that the Jetson can signal the vehicle motors on how to move).

In the upcoming week we are looking to ensure our specific project areas are functioning as expected and are robust, in order to begin integrating components.

 

 

Fausto’s Status Update [04/03/2021]

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).

Fausto’s Status Update [03/27/2021]

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.