Overview:
Firstly, I focused a lot on refining our requirements further, and made a proper outline of all of our Use Case Requirements in as concise of a way possible. I then led a call where I and the team took all of our previous considerations and made Design Requirements directly tied back to these Use Case Requirements. I then transferred this over to our design doc in even more clear language, along with ensuring our Design Requirements had quantitative metrics whenever possible. I also then made most of the tests for our V&V section that satisfied all these design requirements.
Then, with that finished, the main order of business was evaluating all of our parts that we would use again, now that we know what types of parts we would use. While some of the options we picked ended up being our final option, there are a few new things I found. For more depth, see our design document and our trade studies. Most of that was me. But as an overview, I’ll mention some of the important ones:
Part Evaluations:
First up, the IMU. Our initial choice IMU was good for lower power consumption, but considering we are using fairly motors, with significantly more current draw than most sensors, that isn’t necessary for our use case. With some research, I landed on the current robotics industry standard, which is a little more expensive than what we had, but since we had room in the budget for it, it was a clearly better option we should and will use.
Next, the ESP. Brooks and I already put a lot of thought into this, so it was just finding a good price and vendor. One few new considerations was that the one we had has a camera with an IR filter, but because we are in the dark this is not actually ideal for us. However, we can take this filter off manually, so it is okay.
We decided to use motors instead of servos (thus also needing an H-Bridge), as we don’t really care about encoder type feedback, and since we have an IMU we don’t need the encoders to determine speed loops. (we will need to be cognizant of this fact while implementing the control loops, but it is not inoperable). We don’t need fancy, just reliable, so our chosen options are simple and robust with good user feedback.
While reconsidering UWB for our use case of locating survivors again, infrared and heat-sensing came up as possible replacements. We decided against this because it doesn’t allow for us to locate people out of our line of sight. If we needed a line of sight always to determine if a portion of space is not worthy of a SAR team’s investigation, this would significantly slow our system down, and also potentially miss people. UWB can “see” through walls, which is then clearly better, also helps to mitigate the fact our robots won’t be able to reach all locations.
LiDAR doesn’t get cheaper without significantly losing quality than the one we found, so it’s great, not worth discussing further.
Here’s the finalized electrical diagram with our adjustments:
Next Steps:
All of our parts are submitted for order, and I have started designing how our components will all fit together in housing. To keep up with the schedule, I need to have these designs done and prototype housings ready for print by the end of this week. Regardless of if parts come in, prototypes should be completable using online models / spec sheets, and are thus still on schedule even if parts are delayed.
Environmental Considerations:
Our robots are disposable, in the sense that they are cheap enough that a search and rescue team would not be concerned if they lose a robot or two. However, this means we should consider how our robots may impact the environment when lost, as well as possible interaction with the survivors (although this is minimal it should be considered).
One aspect of this is our batteries. If we were to use LiPo, that would not be very safe to just leave in the environment, especially among such a hazardous environment where the batteries could be punctured. Our batteries are instead NiMH, which while not as performant, are safer and more durable, which is great for this application and consideration.
For the body and wheels, which is the largest portion of mass of our system, our solution approach uses PLA plastic. While there are claims and an argument to be made that some 3D print PLAs are less impactful, it still is not great for the environment. However, once designed where rapid iteration is not necessary anymore, PLA can be exchanged for more environmentally friendly materials.
The rest of our electrical components are difficult to address, but all sensors are quite small, and the non-dev version of our UWB board would also have less impact once consolidated away from using the dev board.
Terminal output from npm run test showing 7 test files (24 tests) passing in 483ms: mapLayout, frontiers, integration, lidar, navigation, smoke, and targetSelection.
L. Lu, C. Redondo, and P. Campoy. “Optimal