Either write a script or implement something on the controller itself to make setting the positions, and feedback settings nicer to use.

(e.g. it asks the range of the joint, then tells you to move the arm to x degrees and hold, then y degrees and hold, and it calculates all the settings for you.

Really simple, just needs to PWM the RGB lines based on some state published over CAN bus.

Collaborate with software to determine the message type, and what exactly needs to be done.

Needs to conform to URC rules, however we can likely add some extra features, such as it flashes colours on state transitions. Talk with software about what they would like to see.

Currently it's whatever I've decided to implement in whichever project. This should really be a seperate library that's just #included.

Ideally it should use a circular buffer (with a good implementation!) with a single interface to do CAN init. (maybe pass a function to use to enable GPIO and clocks, with asserts?)

As it exists, the onboarding is pretty terrible. (hrm... I wonder who wrote it)

I believe it should be re-written to actually be thorough, and not assume people will know where to look. It should function more like a tutorial than a list of tasks to finish, because this will be most people's first step into embedded.

The task itself should be similar, but updated for the state we are in now. So it should be reading some sensor value from the ADC, and then pushing it out over CAN.

This probably depends on #36 and #37 getting done.

I am creating this to request upgrading our current ChibiOS as some of the nice features from ChibiOS 20.3 that can be handy for embedded (e.g: MFS).

When using uavcan/equipment/actuator/ArrayCommand to send actuator commands, the third command in the array is dropped. If four messages are dropped, the array looks like this:

[cmd 1] [cmd 2] [cmd 4] [blank cmd]

Reproduced on both arm controller and drive controller.

Steps to qualify:

• Check if it is every third message
• Check if this applies to all dynamic arrays in UAVCAN
• Check path through the iterator that loads elements into this array

Depends on UofA-SPEAR/pcb_designs#46

Evaluate FreeRTOS vs ChibiOS vs NuttX vs any others

We need to have a single libcanard wrapper that is stored outside of each project so that we aren't copying code around, and to have a nice, easy-to-understand interface.

Copernicus II, using the NMEA stuff.

The onboarding task on the Wiki site of this repo seems out of date, instead I think we can delete the page as the README in the front page should be good enough

Using the motor_controller, when adcStart() is called, it triggered the assertion, when test out the ChibiOS original source with branch stable_20.3.x, this problem did not occurred

As the title says, we need to create a board for ChibiOS to use for our dev board.

Goal: publish battery voltage and the current

Platformio is using a default linker script, which likely won't run on any board.

I need to find the linker scripts form SW4STM32 and implement them in custom board files probably.

Currently it's all written in coms.c of motor_controller, whenever some new firmware is started, we should factor out the common functions into their own little module (a folder in common/), to improve DRY.

Once this is done, it would be good to tackle #36

Right now, the feedback coming from the motor controller is pretty sparse and not that useful.

• Add current sensing
• Create new UAVCAN message type to encode the kind of data we want.
• Add position feedback from the motors.

UAVCAN v1 prunes a lot of the standard data types, and instead makes it easier to define custom data types. New data types will need to be written for the various portions of the rover.

This needs to be implemented both on the interface side, and by adding some code infrastructure to make parameters easy.

Since it's C, lots of boilerplate for each parameter is fine, just make it reasonable to add/remove parameters, and some method of versioning so that we can detect when the list of parameters have changed.

Currently how the angles are transformed into the integer encoder positions is quite primitive, and only supports a few hardcoded use cases.

We will need to add a few more CAN parameters and redefine existing ones in order to support a more general array of use cases and redefinitions.

Some specific improvements:

• Reverse encoder directionality. If we send an angle to an encoder, we want to be able to reference opposite of that angle.
• Angle offset. We want to be able to reference an angle we can't reach.
• Change to_radians to something more ergonomic.

Once the computer subsystem PDU is designed, it will need to have a Speedy on it to monitor power rails status (voltage, current, faults).

Exactly what that interface will look like is unknown at the moment.

It would be nice to have a CAN bootloader to update firmware once we have a stable system.

We can use CVRA's very nice bootloader, or make our own if we don't feel like we have enough work to do.

This also includes the tooling around the bootloader, how to actually upload to this bootloader.

Change the linear actuator code to something that isn't so wonky.

We have too many stale branches, many of them for one-off tests that have outlived their usefulness.
Either merge them in or delete them.

As well, old firmware folders can be deleted (AFTER having a known good commit tagged)

This is a tracking issue for the UAVCAN Driver for the Speedy when used with the motor_controller firmware.

It's kind of in a weird half-state right now.

• Migrate fully to Kernel C style
• Rename functions so everything has a consistent scheme
• Move motor functions into it's own source file
• Improve interface between main, motors, and encoders, it's kind of scattered right now. Having a single interface would be better.

Anything else you can think of.

As of now, they only support ArrayCommands. It would make sense to also support single Commands.

Right now we're relying on people to just create a project correctly within SW4STM32. This works but really isn't ideal.

A) it relies on people to not make any mistakes when initializing a project (humans make mistakes)
B) It copies the HAL libraries a lot
C) You have to do a bunch of build configuration to get libcanard running, which is not ideal, as it's easy to forget or mess up, and there's already a few different ways to include the libraries implemented right now.
D) It's hard to retarget. If I want to switch from an F303C8 to a CB, I need to create an entirely new project.

I think the best solution here is just a makefile. This has a few advantages over using the SW4STM32 build system:
A) You can develop/build WITHOUT installing SW4STM32.
B) If we need to add a new use case (e.g. flash storage), we add it once and it works forever
C) Things can be automated. We can do build checks!
D) We can standardize libraries without having to add them in manually to every project (we can just symlink to a single makefile)
E) We can (theoretically) retarget more easily. Different targets can just set different preprocessor defines and use different linker scripts.

Not sure exactly how this will work, and honestly this might take a while to develop an extensible makefile. (+ keep track of pre-reqs so we can give people a nice list)

There is the downside that it's not necesarily as nicely integrated into SW4STM32, but whatever.
It's not that hard to set up an eclipse environment w/ openOCD anyways. Also will be a bit wonky to deal with windows.

The firmware needs to be written for this.

We need to support Voltage and current measurements on each power rail, as well as the enable signals (on by default with the ability to turn it off).

These should use the standard uavcan.equipment.power.CircuitStatus message type: https://legacy.uavcan.org/Specification/7._List_of_standard_data_types/#circuitstatus

It would be quite nice to have printf-style debugging available, so someone should write a ChibiOS "module" (i.e. makefile, header, and source) that sets up ITM channel 0 for SWO print debugging, and hooks it into the C stdlib mechanisms, so that we can use printf to print to debugging.

Don't remember the sensor.

The UAVCAN V0 frameworks are getting maintained by drone folks under the name of DroneCAN. It is a better idea to use their sources there instead of the original UAVCAN

Extract a template ChibiOS application out of the motor controller firmware.

Must include CAN bus, with a thread for CAN and a thread for heartbeat (w/ NodeStatus).

We will migrate to UAVCAN v1 once libcanard has official support for it.

I haven't looked in-depth at the new specification yet, but it looks like it won't be plug and play. (for one, there are no actuator commands, at least when I looked).

Once the CAN refactor is done, blinky can be updated to use it, and serve as a useful, simple example.

Required functionality:

• Blinkenlights ™️
• CAN heartbeat sending
• Heartbeat reception, updating the number of blinks to match the number of nodes it sees

Goal: Just voltage monitoring

Just trying to track progress of getting bootloaders up and running.

Note that supporting bootloaders requires full commitment - each application needs its linker script updated as well.