Author: janyanti

For this week, we focused on getting things ready for the final demo and videos. I worked with Fausto on getting an outline done for the video and we have started to get some of the footage together to start the editing process.

To get our cars ready for this week, we had to fix some issue with drift that came from the mechanics of the vehicle. After spending time in the lab we were able to address most of the drift concerns and now have two vehicles ready for the convoy task.

This week we also had to tweak a little bit of the object detection code to make it more consistent with updating the obstacles. This included a timeout period so that obstacle locations were not spammed. We also added so extra code to mitigate cases where the object depth were not reported.

Lastly I added slight modifications to the communications portion of the code to make sure that the vehicles could communicate seamlessly. With this component polished, we are ready to demo a fully functional project.

The rest of the time these next few days will be spent on finalizing the last couple of deliverables for the project. Namely, the poster, final video and final report.

This week the team worked on integration and getting the system to work completely end to end. This mostly included refining the path planning algorithm to be more consistent and resistant to drip in the data.

In particular, the vehicle mechanics are build in such a way that the car tends to one direction rather than straight. This was due to the wheels of the vehicles not being completely perpendicular. In order to mitigate the issues with physical vehicle drift we played around with PID control to try to maintain wheel velocity at a constant. On top of this we also added an acceleration period to allow the vehicle to build up speed instead of instantly trying to change from one speed to another. This produced much more consistent results and helped to reduce drift but we still saw a little bit of side drift. We also tried to map voltage to our motor velocity scale so that we could get better accuracy for odometry at a given battery voltage (ex: 8v)

We also integrated the object detection algorithm into the flow of the system. For this when we detect an object we report the objects location to the path planner. The planner then adds the obstacle to the map and runs A* algorithm to get a new path for the vehicle to take. The camera lens is also not quite at the center of the vehicle so we have to account for this by adding a slight offset in the Y direction. For now the system gives reasonable results; however, we would still like to see more consistency.

The next week we would like to add additional obstacles, tighten up our systems to be more robust and consistent and add the second vehicle to fully test communication and coordination capabilities.

This week focused on completing the vehicle mechanics and Pose estimation portion of the project. With the new mecum wheels, the vehicles are able to move in any angle direction without angular rotation around the z-axis. This made it better for tracking the position of the vehicle with wheel encoders and IMU sensors due to less overall slipping of the wheels. The code for this was translated into ROS code and integrated to publish the information.

This week I also helped to get the issues with object detection fixed. This involved moving to a Tensor RT base for the neural network inference and switching to mobile net-v1 due to difficulty getting v2 to load. This allowed us to get a much higher FPS (around 30) as well as also drastically reduced the resource usage of the inference model. Further, I added the camera mount and made it to be adjustable so that the angle of the camera could be modified if needed.

Lastly we are tidying up the last couple of path planning loose ends. Namely, the original idea may be a bit unstable due to jittering frames of the object detection algorithm. Therefore I worked on a motion planning algorithm grounded in A* to potentially use if we are unable to smoothen the result from the object detection. This planning does not require too much time (around 0.1 seconds) so the solution should be functional if needed.

This next week will be typing up any loose ends and fully integrating the systems to be fully independent .

The focus for this week was to complete the design of the vehicles with the added battery holder and cuttouts for the optocoupler IR units for odometry. With this design completed I was able to make a final vehicle model out of acrylic which will be used in the actual task. I decided to delay the fabrication of the other vehicles in order to test the current one for potentially design oversights as well as work on other components of the project. Since the vehicles don’t take too long to make this should not be an issue moving forward.

Another thing I worked on this week was writing the wheel encoder code for both the Arduino Pro Micro and the ROS. As of right now we are computing the RPM for both the left and right rear wheel. The calculation for RPM is computed on the Arduino and sent over serial to the Jetson. This is done in a ROS node that publishes the data to a topic. We may consider expanding to have 4 active encoders instead of 2 for better accuracy, but we have to be weary of the I/O requirements and potentially slowdown in sampling speed on the Arduino.

Lastly I worked on preparing more ROS code for the RC control portion of the project. This involved sending commands to the Arduino Uno motor control system over serial after getting update messages. This component works now; However, we need to integrate the IMU for orientation data to create a feedback loop that adjusts the cars motion to match the desired path.

Moving forward, we need to develop the localization and path planning in a ROS environment and connect the various systems together. Most of the localization/path planning work will involve input from the object detection portion of the project. I will be working with Jeffrey to design and implement this portion of the project.

By the end of next week we should have completed our subsystem demos and having most of the core functionality complete. The core task moving forward will be integration and tuning.

This week was focused on completing the drive system for the vehicle. This involved getting some more refined code for the Arduino and Jetson Interface.  The serial communication now works for this portion of the project so the Jetson can tell the vehicle how to move.

This week I also worked on integrating the IMU into the system for localization as well as come up with a way of doing odometry. As far the IMU goes, I have be able to develop code that provides displacement; however, as anticipated there is considerable noise in the system. I used a few techniques to mitigate this noise and found that with a sampling rate of 20hz, the IMU would be about 20cm off within a 1 minute of running. This is somewhat reasonable, but not optimal so we turn to odometry for slightly better results . In particular, we want to integrate an optical wheel encoder for two rear wheels of the vehicle to determine the displacement of the vehicle. By measuring the RPM we should have a good idea of displacement. Since we are using an encoding method that only provides speed and not direction, we can rely on IMU gyroscope data to provide us with that.

The new batteries also came this week and we were able to run a stress test on the system. This included using the UEBC device to power the Jetson. For the stress test I ran the motors at full speed while running some high intesity gpu benchmarks on the Jetson. The battery was able to last longer than 1 hour while doing this. This solution worked well so we can reliably use only one battery for our vehicle.

With the addition of the new batteries and planned odometry I also had to update the CAD model to accommodate the design.  I designed a holder to keep the batteries in place and need to add mounts and cutouts for the optocoupler encoder devices.

Lastly I took the car for a test run on the track with some boxes to see how the driving would work on the track environment. I found the the turns are a little slow due to the higher resistance on the track surface. We may have to account for this by try to turn early in the path planning.

Next week we will try to have the vehicles done including the camera mounts and all design portions touch on above. I also want to transition fully from the vehicle mechanics to the communication and path planning/localization.

This week I spent on getting down the main mechanics for the car completed. This included a lot of testing of the power systems and the motor response. One thing I found was that our original power delivery system with a 9v battery would not be enough to drive the 4 motors. This lead me to research some solutions that could help to alleviate these issues. Namely, we had to address the efficiency of the motor shields as well as the need for higher battery capacity.

The L298N Drivers for the motors draw up to 2A of current at max capacity with a voltage drop of about 3.6v. This meant that the driver was at about 50~60% efficient. For this issue I decided to move to a new solution using the TB6612FNG based Adafruit motor controller. This MOSFET based design was much more efficient with around 90~95% efficiency. This means that the motors get much higher voltages overall and also alleviates some of the power draw issues.

I also looked into new battery solutions for the vehicle. Both the motors and the compute system were too power hungry for our original specifications. For this task we needed a solution that would provide high capacity, high discharge rate and relatively low weight and volume. This lead us to using choosing 2s 7.4v LiPo batteries with 2200mAh capacity. With this we are able to provide sufficiency voltage to the motors as well as the Jetson Nano with a single battery. Notably as the Jetson requires 5v, we also needed to get a universal battery eliminator circuit (UBEC) to step down to 5v. This solution is yet to be tested, but we are confident that it should suffice for the project based on our research.

Lastly I was able to build ‘development’ vehicle to allow us to begin to test the track parameters and any other things that may require a mock vehicle such as data for object detection. The vehicle is able to move with all 4 motor but the Jetson-to-Arduino command system is still in development. Below is a quick look at what the vehicle looks like:

For next week I need to finish developing the control system to work with the Jetson. Once this is done and I have tested the power delivery, we should be good to go with making the final vehicles with acrylic.

 

This week I focused on getting the work done for the mechanical system of the vehicle. I was also able to finalized the parts order and complete the CAD modeling of the vehicle systems. Most of the other work this week was getting the system to allow the car to move. This meant writing a good deal of the Arduino code and testing the circuits for the motors and the motor shield. As it stands the code is able to control all 4 motors with a discrete space to define the direction of the vehicle. In essence, the system controls the motors based on an angle and velocity provided by an external system (compute system) over serial communication. The angles map to various controls to direct the car in the direction of the angle from the horizontal. This is done by specifying a byte over serial in [0, 127] which maps to an angle on the unit circle. The velocity is currently fixed but in the future I would like to add the ability specify the velocity.

Since the parts arrived today I was unable to start the building process; However, will attempt to get at least one car built by the end of Monday this coming week.

As far as the next week plans, I would like to test my implementation of the vehicle control system with an actual built car and tweak as necessary. I think I would also be a good idea to re-parametrize our final testing metrics/specifications based off how the car performs on a simple track test. In conjunction with this, I would also like to start development on the wireless communication platform. More specifically, developing a framework to allow the various portions of the project to coordinate in a ROS environment.

 

 

This week was focused on providing more concrete details about the technology to be used in the project as well as the design and integration.  In particular, I have been able to verify the feasibility of our planned design from the mechanical side of things. One concern that was solved this week was the use of the motor controllers to manage the motor system. We have settled on using two LN298 H bridges to control each motor pair (front, rear). This will allow us to have fine grained control of each wheel to allow for decent car agility. In addition to this, we have been able to finalize almost all of the components (including building materials, fasteners, screws, etc.) that we will need for each vehicle with the exception of exact sensor units for odometry and some power supply units.  With our current configuration of vehicles and parts, we anticipate being able to fully afford 3 vehicles with some budget left over for miscellaneous items, and potentially some experimentation.

This week the team also collaborated to come up with more concrete metrics and testing strategies to evaluate our progress. This has allowed us to narrow down scope and maintain a more focused approach as we continue to fine tune our design.

Moving forward, I need to focus on fabricating the vehicles once we are able to get all the parts. In addition I will also develop the motor system interface to enable the driving portion of the car.

RC Unit (No Camera)