[Subproject] System TUI/CLI

[BenUBC]

• Camera debugging

  • dmesg
  • ID lookup via /dev/v4l/by-id
  • change camera settings live via v4l2-ctl
  • usb root hub health check (lsusb -t and usbtop)

• Ros environment setup

  • Different options (ros desktop or ros base)
  • Option for PIs which only includes necessary packages

• Firmware flashing

• Test sequencing

  • Run a full, automatic test sequence to quickly check that everything works during our setup time

[Roozki]

Why we should have this TUI?

• Camera debugging:

• Difficult to change camera settings on the fly. 1. Commands were long, 2. each camera was different, with different parameters. 3. Sometimes the v4l2 CLI didn't clearly show what parameters each camera had

• Currently DIfficult to check the throughput in the usb hub (max is 10gbps, we think we were hitting 8 gbps). This bandwidth is not super static, and can have spikes. Most cameras had yyuv, which is fully uncompressed.

• Better ID management of cameras, ben had a simple script to add IDs to config quicker.

• Ros / Linux Enviroment Setup:

• Currently, setup_everything_common sets up EVERYTHING. Including downloading firefox on our rasberry pis.... We should better organize what dependencies are on each computer. Potentially, the TUI can build us custom rasberry pi images and load onto SD cards. This could make it a "one stop shop" for setting up everything, instead of a single bash script that just sets up everything the same.
  Long story short: still have one tool for setting up our computers (incl. dev laptops), but better organize and give the user more control over what is installed where)

• Firmware Flashing

• At the least, we want to "hard reset" the moteus drivers. They already support flashing over CAN, so we do not need to plug into them to flash. We should be able to flash the calibration values, and every setting. So we thouroughly test one day, lock down a firmware .elf/binary file respective to each driver, and if stuff happens, we can all back on that file as a source of truth. Rowan can figure out what files/commands we need, Ben can link that up to the TUI

• Test Sequencing:

• Ben wants a sequence that everyone knows, Drivetrain could run each wheel forwards and backawards. People around the field can see each motor moving, then know that it works during setup time.
  Lots of the sequences can be validated automatically (gnss), but motors moving the wrong way need to be validated by people.
  Have a procedure that goes along the test sequence. Make sure everyone knows what they are doing. People should know what to do when a camera is not plugged in. We can have drills for this.

Test sequence hopefully tests everything we have. It should take no more than 5 minutes. 15 minute setup looks like: (5 minute setting up equitment, powering up stuff and network connecting -> 5 minute auto test -> 5 - 10 minutes of debug time)
Tests:
**1. USB Tests: (check dmesg or /dev filenames to make sure all usb peripherals are plugged in)
2. GNSS test (check that we have a fix, check that its plugged in)
3. Camera test (make sure each camera can pull a feed, maybe make the TUI pull up the live feed)
4. Asking us to move the joystick, validating that the whole control pipeline is healthy (joystick -> custom nodes -> hardware interfaces -> hardware -> physical motors).
5. CAN lines (are they healthy? are there error states? Are all heartbeats popping up? Communication stress test?
6. Ping each computer, make sure every pi, onboard and base computer is online and talking.
7. Drive Motors: Run forward backward for each motor, while people have the rover elevated. People will then call back if something is wrong (motor spinning in wrong direction or not spinning at all.
8. Comms base: Rotate clockwise, counter clockwise, make sure motor is OK.
9. PTZ, pitch, tilt, zoom. Make sure thats all working.
10. Lighting for night tasks, verify via camera feeds or people around, have them go through a sequence individually.
11. Battery telemetry (make sure cell voltages are healthy and charged, make sure temp is not going all wild)
12. Similar to 11, but PDBs should have telemetry on maybe current, temperature etc. We can drive a motor, then detect current being pulled.
There will be more, but we cant think about too much
Ben will catagorize for the fully automatic, but less automatic we need steps in the procedure.
**

Some of the tests, the TUI can just sub to the ros topics. Maybe the TUI needs to run custom launch files. Quick "ros2 wtf" test (might not be needed, usually only detects problems in configuration). Maybe ros2 graph to show what topics and nodes are running visually

Side Notes:
We probably have to upgrade to Ubuntu 24 and latest ros2 LTS

• Isaac ros package was not able to be used. Ben was not able to download on humble because ros2 humble is a bit older, and isaac seems to be focused on the latest LTS ros2 releases.
  Single or double jump?
  2 choices, single or double jump (22 -> 24 or 22 -> 26 Ubuntu)
  24 Ubuntu: Jazzy Jalisco, EOL 2029
  26 Ubuntu: Lyrical Luth, EOL 2031

Repo organiziation:
No more cameras_cpp -> cameras with PTZ

One hardware interface package (arm_hardware_interface, etc)

[Roozki]

Implementation:

1. Textual, for clean, graphical and colourful feedback of whats going on