Motor Driver Settings Engine

I've now added quite a few functions to the debug command-line interface of my modular motor driver. There's a variety of categories of functions, but the two main categories that have exploded in number are the settings & motor related functions.

Settings Engine

As I've mentioned in the past, storing settings for calibration (and plenty of other smaller, but still significant, purposes) are crucial for the modular motor drivers to avoid severe headache with image build management.

How does my system work? Hopefully the slightly convoluted diagram below illustrates this well:

Crystal clear? Perhaps a little explanation to go with it might help...

All of these commands/functions can be controlled via the command-line interface (currently accessed via the debug UART), however the software automatically runs some of them too. At boot it will read the stored settings from the EEPROM memory, after performing some checks (like checking that the settings version matches the one that the code understands, and that the settings are valid) it will then load them into the current/run settings that the main loop uses.

The staged settings aren't strictly necessary, but they buffer between the EEPROM and the current settings. This allows some checks to happen before they're applied to the current settings (which potentially can cause bad things to happen if the settings aren't reasonable). It also allows one function to display both the current and stored settings depending on whether settings-save or settings-read was most recently run.

Otherwise, the "set" and "motor-set" functions can be used to directly update the current settings. At some point maybe it would be good to have these update the staged settings and then a settings-load would be required for them to take effect, but many of these were implemented before the settings system existed and I didn't want to change them just yet since I quite like being able to directly edit the running settings directly at the moment - I'm playing around with them quite a lot at the moment and the software safety limits I have in place negate most of the risk that's associated with allowing direct access to them (which I'll probably remove/relax at some point).

Is this the best way of implementing any of this? I'm not sure, but it works pretty well for me at the moment, so I'm in no rush to change it in any significant ways in the near future.

Settings Contents

Below is an example of the contents of version 2 of my settings content (mostly the same as version 1, with the "current reversed" parameter added) after running settings-print.

After the settings version and an indication that the settings have been set and are valid, the current settings version gives me some details about the board hardware type, and a serial number to track the specific instance of board.

The bulk of this relates to the motor control though. These have their own validity flag (this allows settings relevant to board to be set while indicating settings that are specific to the motor to be ignored until motor calibration has been performed, perhaps at a later date). The motor settings section currently stores the following information:

• PI (proportional & integral) gains for torque, velocity, & position control
• Reversal/inversion of current sense & encoder readings
• Calibration offsets for current sense channels & motor encoder

Next Steps

I feel like a bit of a stuck record here, but I'm still working on getting the motor control (and a few other bits) running as smoothly as I'd like. That might involve switching over to an RTOS (Real Time Operating System) rather than running bare-metal, but I'm still internally debating that decision.

It might be a little while before my next post as I'm largely caught up on progress now and I'm not sure when I'll next find the time to make some solid technical progress. The pressure to get this working has been alleviated a little recently though as Henry has revived some of the 2024 hardware for the purpose of testing some of the high-level software.