control.rs and main.rs do not populate telemetry with breakbeam status (returned from control.rs around line 540)

We'll eventually need to be able to include the motor driver firmware into the main firmware image to be distributed. I think the easiest way to do this would be to write a small python script that can read a file (or text input), and take a label name, and generate an assembly/C stub with the byte contents, byte length, and crc32 checksum. We can then directly map the symbols in the linker file.

Right now the setup for USB passthrough on Win 11 is manual. It might be nice to automate this for others.

Because of low side current sense, we don't get direction for torque control so we rely on encoders. In the velocity loop we don't want to oversample the encoders because it will lead to instability. However, we can read the encoder without clearing more often just for direction for torque control incase there is a commanded flip before velocity is read.

We couldn't tell that the kicker board was off. We should

ugh

Kicker overvoltage lockout behavior currently has some quirks that should be addressed.

1. Kicker errors are not reported upstream (either at the kicker or control firmware level)
2. Kicker high voltage measurements are not filtered
3. Kicker has no mechanism to unlatch errors

2 and 3 are interacting negatively. Occasionally it seems measurement occurs when there's a small spike (probably on kicks). The target voltage is 182, and the over voltage lock out is 190, so ~4% error. I think there are a few options to solve this, but they need careful thought. We could bump the lockout voltage, but we need to make sure it below 200V enough to stop charging before we cross 200V based on the simulated or observed charge rate. Another option might be to filter measurements (we should do this anyway at least for the value sent upstream), but again we need to make sure the filter delay doesn't mean we stop charging too slowly.

It looks like PA5 Pull-Up isn't working, which means the encoder detection fails reading as connected.

The IMU code is pretty bare bones. This should address the motion improvement requirements set by @joe-spall. I suggest:

• Move the IMU reads into their own task
• Have the task block on device interrupts
• Enable interrupts on the BMI085 after gyro conversion, fire SPI DMA transfer
• Double check the BMI085 settings for data rate vs noise. It may be updating much faster than we need and would have noise
• Add an optional filter
• Add accelerometer data fetching at the same time we use DMA to get the gyro data (these may have different acq rate, prioritize gyro)

There's already a pubsub channel setup for IMU data that collin used for the o.g. prototype. This should be task/thread safe.

Don't need to flash everything every time if it's the same image.

It'd be super helpful to have an automated gdb target to open openocd in interactive mode, and then attach a debugger. It looks like someone has done that before here https://cycling-touring.net/2018/12/flashing-and-debugging-stm32-microcontrollers-under-linux.

No error flags are currently reported and the packet definition has some old and some missing flags

Details are murky but sometime robots require two re-connection cycles when software radio bridge is restarted out of band.

Steps to reproduce:

1. Start radio bridge
2. Start robot
3. Wait for positive connection
4. Kill and restart radio bridge
5. Robot will connect
6. Robot will disconnect and reboot
7. Robot will connect and stay connected

step 7 should occur at step 5

On WSL2 if running udev_setup.bash after update-alternatives has been set for usbip, the line
update-alternatives --install /usr/local/bin/usbip usbip /usr/lib/linux-tools/*-generic/usbip 20 fails with
update-alternatives: priority must be an integer

This causes the rest of the setup script to not be run. This error also occurs if the line is ran from the command line. I am speculating its because the priority is already set? 20 is clearly an integer.

Commenting out the line lets the rest of the script run.

We've got much better error detection and handling at the stspin layer and can detect missing PCBs, but the way we handle this info is missing or blunt. Notable examples are a system power reset when comms time out, and no detection/correction for faulted motors. We should have a global estop manager that aggregates failures and contains some of access control list type of thing where major functions are enabled or disabled based on the aggregate of current errors (e.g. dribbler fault should not stop motion, a single motor failure should arguable not stop motion but restrict it, two motor failures should certainly stop motion, specific failures should automatically trigger kicker auto discharge).

We should consider at least the following list or errors:

• dribbler failures
• single motor failure
• multiple motor failure
• unplugged radio
• comms timeout
• unplugged IMU
• IMU failed self test
• unplugged kicker
• low battery voltage
• critical battery voltage

We should consider the following classes of actions:

• forcing reduced motor velocity
• forcing 0 motor velocity
• forcing power off / lower power state
• forcing kicker discharge procedure

Might be interesting to measure charge rates of kicker over time to detect faults/ measure performance. Would send up to control. Reset count after kick/chip

This isn't a firmware or software issue per se, but a list of things that should be standardized between the sides and aren't. This is a living list.

• we have no standard terminology for "body velocity", the Vec3 in robot motion command. Software simply calls this twist because that's the msg type, but we may conceivably use multiple twists for position, vel, accl, torque at various points
• we have no agreed upon terminology for clamped, limited, whatever versions of raw commands
• we have no agreed upon structure for wheel based data, e.g. float32[4] arrays for each data point, Struct[4] containing all data points per wheel
• software and firmware use different wheel state spaces (e.g. indices for ordering in arr[4] types)
• broadly, some control packet data names are misleading or bad, some feature mismatches
• software and firmware use different names for firmware: "control debug telemetry", software: "RobotMotionFeedback"

• HPF across outboard inductors (1nF, 1k)
• BOOT0 pull down
• Fix PGOOD LED
• Vbatt sense
• 3v3 sense
• uC_KILL pull up
• Kick Chip silkscreen
• local 8MHz clock?
• layout

Looks like the template to collect sources and build a firmware image is gonna be extremely cookie cutter. This can probably be made into a macro. Then the top level CMakeLists.txt file will be fairly clean and we won't have to get crazy with sub dir files.

Especially in radio.rs

We seem to observe this behavior only with a negative DC setpoint. We might have a sign based logic bug somewhere when setting DC on the stspin firmware.

Steps to repro: set DC -0.2 (observe behavior after a few minutes), set DC 0.2 (do not observe behavior after a few min)

udevadm control --reload failed if already running. Got the error of
Failed to send reload request: No such file or directory

Resolved by running
sudo service udev restart
and the udevadm commands needed

Maybe catch on this error and echo with suggestion of running above?

something causes stspin uart to freeze without locking up the whole device (doesn't trigger watchdog). We've temporarily added a watchdog trigger to clear the condition with a reboot.

Adds timeout recovery, don't flash everything in paralélelo, etc

Could be physical or special radio packet

Need to test drive, dribbler, kicker?

Auto-discharge runs without considering the breakbeam. However, if someone goes to pick up the robot, a finger could be in the mouth of robot. Invert the logic and stop the auto-discharge if breakbeam

This probably rooted in queue.rs or uart_queue.rs. Needs some deep debugging work.

Probably best to hold off until the 1.79 compiler migration for 2024 bot.

Convert radio body velocities to wheel commands

• change ambiguous verb/noun names/functions
• battery voltage is sent back to ROS
• torques are sent back to ROS
• wheel vels are sent to ROS
• IMU theta, xz accel

The motion code has some rough edges, especially as we've added features like parameter updates. Things that should be cleaned up:

• matrices should have names not mathematical letters/syms
• there should be a clear delineation between hardware and control models
• PID module needs to be refactored into a single state module, not a parametric type. This has implications for matrix slicing when parameters are updated, and currently makes the code pretty ugly
• parameter updates should be dispatched hierarchically using some form of trait for updates. This will make pieces interchangeable.
• Modules should have prints at correct logging granularity and crate level logging should be error or off by default