Team Status Reports

Team status report for 10/17

We had a big setback for the design. The following was accomplished this week

  1. Ethan debugged the setback and proposed alternatives (see his status reports for more detail)
  2. Alden characterized the motors.

We had a major setback where our power system is insufficient to power the pi. The risks of the fixes seems low because a powerbank seems to be able to power the pi on it’s own, meaning that the only work we need to do is to intergrate the powerbank on our mechanical chassis. If we choose to use a buck converter instead, we will need to change our design by hooking the buck onto the motor drive battery.

 

Triaging that and fixing it took up most of the week and therefore we are behind by a week and have to move everything in the schedule over by 1 week. Thankfully, we have 3 buffer weeks we can use.

Updated schedule

In terms of special prompts, Ethan worked on part A, and Ben worked on part C.

Team status report for 10/10

We are one week behind schedule as we still have not determined the mechanism for dropping the repeaters.  Ethan spent most of this week working on the report, and Ben was busy because of interviews.

  1. Crawler is wired up and all mechanical components except for repeater dropping are built and fits
  2. We determined we have the repeaters tell the crawler it needs to be dropped in software through a reticulum message. This has been tested.

We shouldn’t need to amend the schedule at this point because we can still meet integration deadline. There are no major setbacks or design changes.

Team status report for 10/2

We are mostly on schedule, slightly behind on the crawler v0 build out. Major accomplishments this week:

1. WiFi mesh repair optimized and tested for 2+ hop paths

2. Crawler v0 test prints for fit

3. Crawler v0 CAD finished

We shouldn’t need to amend the schedule at this point. Integrating sensors and drive control into the first crawler built is highest priority, aiming to finish by end of next week.

We are behind on testing the repeater drop mechanism. We need to test both an electromagnet + soft core magnet, or push-pull solenoid mechanism. Then, update the CAD to integrate this. For now, we can parallelize the software testing for repeater drop heuristics by doing an un-actuated mock drop (human drops it).

Team status report for 9/26

We are mostly on schedule. Major accomplishments this week:

1. Synthetic scenes for odometry/vSLAM, obstacle avoidance created

2. Odometry/vSLAM, obstacle avoidance algos tested

3. Motors tested, encoders tested

4. Router v0 software close to completion

One setback was that we accidentally broke our motor encoder of one of the 2 motors that arrived this week. We believe we might have forced too much current through it, though we are not sure. This is a setback for our IMU + SLAM integration because they rely on robot speed as an parameter. We have already ordered another motor, which should arrive in about 2 weeks. We will parameterize over the encoder, such that we can run traversal and odometry with or without encoders.

No significant changes were made to the design.

In terms of schedule, one week was added to design crawler (must finish by week of 9/27). We have most of the CAD for crawler_v0(cannot drop repeaters yet) done, and we should be able to start printing it next week. And one week was added to test+integrate SLAM/IMU because there are so many parameters we need to explore. We don’t believe that this will impact our start date for system integration as of right now. Here is our updated schedule: https://docs.google.com/spreadsheets/d/1DqsZSAYtfRcWDvpkXF5V4PL6xXMno_pSEzeaO8iDq3M/edit?usp=sharing

AI Citation (Summary, used AI very heavily)
1. Ethan: see Ethan’s status report for more details
Week 2 special Questions
Part A: done by Benjamin
Global warming causes increased vapor in the atmosphere, and increasing sea temps. This leads to stronger storms, and higher wind speeds, respectively. As natural disasters become more frequent and destructive, we must invest in technology to protect and recover humans. Our capstone project will develop coordinated robots that are capable of locating humans, allowing efficient use of limited rescue resources. In disaster scenarios, society will be able to recover faster with fewer lives lost.
Private sector has no interest in protecting & repairing after natural disasters. This technology requires government investment, for the safety of all people.
Part B: done by ______
Part C: done by Ethan

This part is probably the least relevant compared to part A and B because the main purpose of this project is to help in disaster scenarios and save lives. The specific need is that rescuers are often extremely short staffed and overextended during times of disaster because there are not enough resources allocated to them (see guardian article). After all, it is not easy to find individuals with the necessary training, and the government must provide them with equipment to protect them from hazard, which is very expensive.

Therefore, an economic argument can be made for this need because the issue with overextension is largely contributed by poor resource distribution to rescuers; our project aims to make search and rescue more efficient and safe, which helps alleviate this bottleneck. First, our robots are able to explore areas for rescuers and therefore reduce part of their burden. Additionally, each crawler is relatively cheap and replaceable. Beforehand, a human rescuer might need to risk his/her life to explore a dangerous area. Our crawlers can be used for the riskiest parts and therefore reduce the time needed for humans rescuers to be in danger.

https://www.gao.gov/blog/fema-staffing-shortages-could-mean-disaster-future-response-efforts

Team status report for 9/19

This week, I think we made a lot of progress this week and there is no major concern on falling behind. The main achievements this week are that

  1. The cad of the robot-v1 is almost finished (see more detail in Ben’s status report).
  2. The routers can now run reticulum on AP-STA mode (see more detail in Ethan’s status report)
  3. Slam is getting simulated (see more detail in Ben’s status report)

The most significant risk right now is that we might not have the compute capability on the pi5 to run SLAM. This concern is currently being simulated by creating synthetic video and running slam on the synthetic video. Based on the simulation so far, we think it less likely that this concern is true. See Ben’s status report for more details.

No changes were made to the system or schedule this week.

Media
Our Cad

Orbslam running on synthetic video. Please download from google drive because the file is too large

 

AI Citation: Summary: we used AI very extensively it is essentially a work buddy. Here are some of the notable contributions

  • AI did the following (I (Ethan) might have missed something)
    • AI is the one who is creating the synthetic video and running slam on it. We think this is an ideal task for AI because it involves just running a lot of public code/frameworks. Additionally, this is just an initial messing around test, so we don’t really need to verify the work of AI in this stage.
    • AI created almost all the code inside https://github.com/brcolby/gestalt, which is a of test code + code for the Cralwer
    • AI modified the t-beam firmware to support GPS, Ben tested this and it is reliable.
    • AI contributed a lot to the routers (see Ethan’s status reports for more detail)