213 parameters add new api to clear parameter from mcu flash#214
Open
mlecriva wants to merge 6 commits into
Open
213 parameters add new api to clear parameter from mcu flash#214mlecriva wants to merge 6 commits into
mlecriva wants to merge 6 commits into
Conversation
Brings in the firmware-side parameter_handler reset command needed to clear parameters from MCU flash, along with the FlashDB-backed KV storage and persistence policy it depends on.
Plug the firmware-side parameter_reset command into the Python toolchain so a parameter can be cleared from MCU flash from the firmware_parameter_manager. - New reset_parameter_value / reset_all_parameters methods - New SIO event chain reset_parameter_value/_response - New CAN UUIDs 0x300B / 0x300C in copilot - FirmwareParameter accepts ParameterResetRequest/Response in pb_copy and pb_read
Brings the generated bindings in sync with PB_ParameterCommands.proto after adding ParameterResetRequest / ParameterResetResponse, so the firmware_parameter_manager -> copilot reset pipeline can import them.
Only PB_ParameterCommands had been regenerated against protoc 5.29.5; the rest of cogip/protobuf/ still carried the pre-guard gencode. Keeping two gencode generations side by side is a latent import hazard — newer google.protobuf releases tighten ValidateProtobufRuntimeVersion — and it means every targeted proto refresh produces a noisy mixed-style diff. This regenerates the remaining 11 messages and their .pyi stubs from a single protoc 5.29.5 invocation so the package is internally consistent and future regenerations stay scoped to real schema changes. No proto sources, message fields, or wire formats were touched.
…to an interactive shell The previous tool was a one-shot diagnostic that dumped every odometry parameter once and exited, which is fine for a smoke test but useless when an operator actually needs to tune a running robot. Now that the firmware exposes the full motion-control parameter catalog plus a reset API, the manager becomes a tab-completed REPL so parameters can be inspected and adjusted live without restarting the tool. - Replace the read-all-and-quit flow with a `get`/`set`/`reset`/ `reset-all`/`list` shell driven entirely by the supplied schema. - Ship a bundled `firmware_parameters.yaml` covering the seven motion-control sections declared by the firmware, so the default invocation is useful without extra arguments. - Add `FirmwareParameterSchema` and `FirmwareParameterSection` as presentation-only models: they group parameters into named display sections while keeping wire addressing by FNV-1a hash unchanged. - Probe parameters at startup and mark NOT_FOUND entries (e.g. OTOS on non-OTOS robots) `<unavailable>` so the REPL stays correct across robot variants without per-robot config files.
Contributor
Author
|
b502273 should target the mcu-firmware master branch before merging this PR. |
mlecriva
force-pushed
the
213-parameters-add-new-api-to-clear-parameter-from-mcu-flash
branch
from
dc487f6 to
cfe1da5
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds a parameter-reset API end-to-end (MCU firmware → CAN/SIO pipeline → Python tooling) and turns the
firmware_parameter_managerCLI into an interactive REPL. It also realigns the rest of the protobuf gencode with the 5.29.5 runtime thatPB_ParameterCommandsalready used.Note
Only the PID gains and odometry parameters are currently routed and consumed by the firmware. The speed and acceleration limits are declared in the parameter database to prepare the ground for future use, but modifying them has no effect on firmware behaviour today — they are only useful to exercise the flash-storage path (set / reset / persistence across reboots).
Commits
submodules: update mcu-firmware to expose parameter reset API— bumps the firmware submodule to pull in the newparameter_handlerreset command, plus the FlashDB-backed KV store and persistence policy it relies on, so a parameter can be cleared from MCU flash.tools: add parameter reset support across the SIO/CAN pipeline— wires that firmware command into the Python side: newreset_parameter_value/reset_all_parametersmethods, matching SIO event chain, CAN UUIDs0x300B/0x300Cin the copilot, andFirmwareParameter.pb_copy/pb_readsupport for the new request/response messages.protobuf: regenerate parameter commands with reset messages— regeneratesPB_ParameterCommands_pb2so the newParameterResetRequest/ParameterResetResponsemessages are importable by the reset pipeline.protobuf: align all gencode with the 5.29.5 runtime— regenerates the remaining 11_pb2.py/_pb2.pyifiles against the same protoc 5.29.5 used forPB_ParameterCommands. Avoids a latentValidateProtobufRuntimeVersionmismatch from mixing gencode versions and keeps future single-proto refreshes free of unrelated formatting churn. No.protoschemas or wire formats changed.tools: firmware-parameter-manager: turn firmware parameter manager into an interactive shell— replaces the previous one-shot odometry dump with a tab-completedget/set/reset/reset-all/listREPL driven entirely by a YAML schema. Adds presentation-onlyFirmwareParameterSchema/FirmwareParameterSectionmodels (parameters are still addressed on the wire by FNV-1a hash), ships a bundledfirmware_parameters.yamlcovering the seven motion-control sections declared by the firmware, and probes parameters at startup so variant-specific entries like OTOS are marked<unavailable>on non-OTOS robots.