Ethan’s Status Reports

Ethan’s Status Report for 10/17

We hit an unexpected bump because we are not able to power the pi5 using our current powertrain. I did the following (much more detail in slack)

  1. Identified  and fixed the issuehind this
    1. Our boost converter was bad and cannot actually power the pi at high currents. Fixed this by testing new boost converter from roboclub
    2. Using a single 18650 might not be enough current wise. Tested that 18650 can provide 1.8A, but not sure if we can go over that. We will likely need 4 18650s. Therefore, we should probably use a buck instead and connect the pi to our motor battery. Order the buck with my own money to test.
    3. Used AI to design benchmarks to stress the pi5 cpu. Found that should draw no more than 2As (drew 1.8A when running gemm4 using NEON/SIMD on all 4 cores).
      1. This also helped us determine that wire resistance is nontrivial. We have experienced brownouts when the CPU is stressed/high current because the wires drew too much current and therefore dropped too much voltage.
      2. Since our pi should draw no more than 2A, a powerbank might be enough to power the pi. I bought a 2.4A powerbank and it seems to be able to power the pi reliably and run the gemm4 workload without brownouts or low voltage warnings. This is also cheaper than our buck converter.

Part A:

There are many global factors for our project and our project is intended for a scope beyond Pittsburgh or CMU. Our project is meant to be a testbed to evaluate reticulum’s viability in robotics, which can be considered academic. However our project is also a search and rescue robot whose key feature is a highly flexible network stack, meaning that it could be used with an variety of situations all over the world. Additionally, our important goal is that our project is built using readily accessible parts that are cheap, making this ideal for use by anyone across the world. After all, many institutions cannot afford to deploy robots that are over 10k each, but a $600 robot changes the affordability issue significantly.

What I fell behind on

  1. Get motor fully set up (encoder), I tried to work on this on saturday, but techspark is closed.

Next Weeks tasks

  1. Get remote controll working on 1 motor with the pi.

Ethan’s Status Report for 10/10

I spent most of this week working on the design report, so did not get that much work done. My main accomplishment was to get both pi5s set up and test pubsub on the pi5s. Then, I had the 2 pis communicate with one another over pubsub + reticulum using my home wifi.

What I fell behind on

  1. Get motor fully set up (encoder)

Next Weeks tasks

Get remote controll working on 1 motor with the pi.

Ethan’s Status Report for 10/3

I accomplished the following this week

  1. finished reticulum V0 software, network can repair itself in about 30s if a router dies
    1. The current architecture of the router means that the router chain might break if a router dies and rejoins. This is because a router wifi will always be set up before it’s reticulum is configured. Downstream routers send announces immediately when it changes the AP it’s STA connects to, but that annouce will be missed by as reticulum is not yet set up on the router that just went online. This can potentially be solved by having the router send a broadcast message asking everyone on the network to annouce, but the tradeoff is that it costs extra bandwidth
    2. I believe issue 1 should not impact us much on our MVP demo, so I will shelve it for now.
  2. Tested mac –(gestalt4_hotspot)–>pizero4_router –(gestalt3_hotspot)–>pizero3_router –(gestalt2_hotspot)–>pizero2_client. If I unplug pizero3_router, the system will automatically reconfigure itself to mac –(gestalt4_hotspot)–>pizero4_router –(gestalt2_hotspot)–>pizero2_client in 30 seconds.
  3. Decided to use the AI coded pubsub rather than implementing it from scratch

What I fell behind on

  1. Set Pi5 to run Gestalt repo code + get AP_STA mode set up on Pi5
  2. Get motor fully set up (encoder)

Next Weeks tasks

  1. Help Ben with building and integrating first robot chassis.
  2. Potentially start running slam + IMU on the Pi?
  3. Potentially give routers LORA support?

AI Citation: Summary: I used AI very extensively it is essentially a work buddy.

Ethan’s Status Report for 9/26

This week was not as productive as last week, the following is accmplished

  1. Test the basic hello world server on multi hop to see how announces work, one important learning was that transport nodes can automatically forward announces despite not announcing themselves.
  2. Reticulum software_V0 is almost implemented. This turns out to be more complicated than I expected (specifically bullet 2) It can do the following
    1. automatically find the best parent network to connect to
    2. After the network topolgy is changed, it can tell it’s children to reannounce themselves.

What I fell behind on

  1. Create Basic pubsub framework, but there is currently a debate on wether to reimplement pubsub from scratch, or use the current AI-Coded one that Ben uses in his tests. There are pros and cons of each case, will need to talk to Ben next week to make final decision
  2. Set Pi5 to run Gestalt repo code + get AP_STA mode set up on Pi5

Next Weeks task 

  1. Finish up router software
  2. Test router software
  3. Settle debate over whether I should implement pubsub
  4. Start some motor work (motors arrived)

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

  1. I architected what the router software should look like and what to do with announces after topology changes (ex. a router died). I essentially gave it rough phusedocode highlighting the key functionality + design intent, then AI wrote the router software implementation and got it to run on the pi0s. The then reviewed all the code AI generated.
    1. AI explained/summarized what is currently there is the Gestalt repo

Ethics Question: Part C

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

 

Ethan’s Status Report for 9/19

This week was quite productive. The flowing was accomplished

  1. Learned about the high level basics of pubsub
  2. Got a reliable way to set up AP-STA mode in pi0s (2 scripts)
  3. Got reticulum to run on AP-STA mode pi0s, and
    1. reticulum is able to set data either downstream through AP or upstream through STA
    2. Reticulum is able to detected devices either downstream or upstream in using RNSatus
  4. Tested the following
    1. Pi0 has good wifi range (at least 20-30 meters, if not more)
    2. Reticulum is able to send packets and natively support multi hop
      1. MacA —(gestalt-3 hotspot)—> pi3 —(gestalt-2)—>pi2, macA can send packets to pi2
      2. MacA —(gestalt-3 hotspot)—> pi3 —(gestalt-2)—>pi2 —(gestalt-2)—> macB macA can send packets to macB, if macB instead connects to gestalt-3, reticulum will notice and adjust, but probably first doing an announce
  5. Implemented a basic basic hello world server/client using reticulum API to better understand how announces work

What I fell behind on

  1. Test the basic hello world server on multi hop to see how announces work
  2. Read more on pubsub

    Next Weeks tasks

    1. Create script to let router connect automatically to parent router when it turns on. In the MVP, this will be done by by having the router search for the hotspot whose id is 1 more than the id of the router
    2. Create basic pubsub + protobuf framework

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

  • AI did the following (I might have missed something)
    • Created scripts (python+shell) to set up AP-STA mode, this is essentially a stream of linux commands that sets up a bridge and disables features such as multicast in our network driver (multicast breaks reticulum for some reason).
    • Created a very simple shell script to quickly connect a pi to a network
    • AI also helped created the skeleton of the hello world server/client, which I then modified for it so that the user can control when to announce + send data
    • AI taught me pubsub + protocol and the advantages of them. I have never encountered these before so I learned a lot.