Tag: status report

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

One significant change we made was switching from the Jetson Nano to the Jetson Orin Nano. This was necessary as we became cognizant that the Nano’s compute might not have been sufficient to run ROS, Object Detection, and SLAM simultaneously. We also saw that it took the Nano 40 seconds to run YOLOv7. In terms of costs we incur we were lucky that the Orins were available in inventory so we didn’t have the shell money out of them from our budget. An additional cost is that the Orin needs to be supplied with a higher voltage so we have to upgrade a hexapod’s power supplies to meet its demands.

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

Currently, our greatest troubles has been in bringing up the Jetson and Raspberry Pi boards to run all the relevant software that we need (ie. ROS, YOLO, Jetpack, & Python versions meet requirements). This has taken a bit more time than previously planned, though we have learnt many things.

Since we did just swap from Jetson Nano to Jetson Orin Nano, we will also need to make sure that the Jetson Orin Nano does not have any hidden requirements.

Provide an updated schedule if changes have occurred.
We will have to extend our scheduled time for setting up Jetsons (since we changed to the Orin). It’s a good thing we have slack!

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

Currently, we are running into some issues with testing out YOLOv5 on our Jetson due to some of the packages and dependencies being out of date. We’re putting a lot of effort into figuring out which parts of the dependencies are outdated and trying to manually install alternatives. A contingency plan is to try out a newer version of YOLO in hopes that the dependencies would be more up to date and better documented. 

 

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

If possible, we are considering removing the Raspberry Pi from the Hexapod and using the Jetson Nano to perform all the actuation of servos. We will just need to confirm that the Raspberry Pi shield from the Hexapod is compatible with the Jetson Nano.

 

Provide an updated schedule if changes have occurred.

No major changes. We have completed the assembly and bring-up of one robot, as well as setting up a Jetson; now we are trying to train a YOLO network on the Jetson. One thing is we have decided to only order and start with one hexapod rather than all 3, so we are a little behind in that aspect. However, we believe that we will be able to do the bring up for later hexapods much faster.

 

This is also the place to put some photos of your progress or to brag about a component you got working

Please write a paragraph or two describing how the product solution you are designing will meet a specified need…

• with respect to considerations of public health, safety or welfare. 

The Crisis Critters are intended to help find victims of natural disasters (ie. Earthquakes, building collapse) fast and efficiently. We believe that by finding victims earlier, we can prevent deaths and further deterioration of the victim’s health. Furthermore, these robots also reduce the workload and risk that human rescue teams face in these dangerous environments. 

 

• With consideration of social factors. 

Computer vision algorithms have historically had problems with biases in the dataset that its being trained with. For example if we train our product with images of people from only one race it might not be able to identify other races. To remedy this we need to have people from different races to make our solution race invariant. 

• with consideration of economic factors. 

With the increase in natural disasters in addition to conflicts around the world, the need for cost effective methods of search and rescue are rising dramatically. The integration of sophisticated autonomous robots would be integral to expediting the SAR process in areas of need. The production of these hexapods will be cheap and would be widely available due to the relatively low cost of the hardware and the public nature of the required software.

The most significant risk right now is whether or not the hardware for the hexapod works well and whether our current search algorithm is effective for the use case. As contingencies we have other hexapod models that we can order if our current one does not function well and we also have looked into alternative search algorithms for our swarm.

Upon further design discussions, we realized that we would need to implement some sort of SLAM algorithm to ensure that each hexapod can know where they are within the search area. This is important because internal tracking of distance can be erroneous due to any slippage on the hexapod. We also need SLAM in order to guarantee that our hexapods can find each other if there are cases where a hexapod carrying first aid needs to reach a survivor that a separate hexapod has located. This adds a bit of time cost to our project and it also may require us to purchase a better camera module or a lidar. We believe that we can still get these parts within our budget and we will do more research into finding the most cost effective solution.

This change means that we need to add an extra week of research and testing on SLAM into our schedule. We will all be working on this during an upcoming week within February.