[GH-ISSUE #5026] [Design] Scope for ODrive motor-control firmware #3090

New issue

Closed

opened 2026-10-31 00:36:27 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:36:27 +00:00

Owner

Originally created by @h-oiwa-dseiko on GitHub (Oct 18, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5026

Before submitting

I searched the open and closed issues and pull requests for a related discussion (search: “ODrive firmware motor”; no matches found).
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This discussion does not include credentials, private samples, or sensitive target data.

Decision needed

Does developing or hosting an ODrive v3 custom firmware in REA that accepts FFBeast-compatible USB force-feedback reports and commands motor outputs fit the contribution scope? The proposed extension includes using M1 to add torque to M0 on the same wheel axis. If this is in scope, what exact behavior boundaries and verification conditions must be met before integration? If it is out of scope, should the firmware remain in a separate project?

Context and evidence

The supplied FFBeast ODrive HEX has been statically inspected. Its target is consistent with STM32F405 / ODrive v3 hardware, and one PWM output path was traced. The analysis does not establish that the image drives M1, the physical torque/current conversion, or a verified watchdog and motor-stop path. The matching firmware source was not available.

As source-derived evidence about a possible alternative base, public ODrive fw-v0.5.6 v3 source constructs separate M0/M1 motor and encoder objects on TIM1/TIM8 and TIM3/TIM4. Its INPUT_MODE_MIRROR reads the selected axis's torque_output_ and multiplies it by torque_mirror_ratio (default 0.0); it also mirrors position/velocity setpoints. This is not evidence that the supplied FFBeast image uses the feature or that a same-wheel setup is calibrated or safe.

A host-only prototype models parts of the HID/effect behavior and a fail-closed M1 torque-mirror calculation. Its CTest suite passed, but no target firmware has been built or flashed and no motor or ODrive was operated.

Expected interaction with targets

Change process memory or registers. A running firmware would write motor-control/PWM registers and can physically actuate an attached wheel. No target interaction has occurred during the current prototype work. Network, persistence, and protection-bypass behavior are not proposed; the firmware's required startup, stop, timeout, and fault behavior still need review.

Boundary details (optional)

The intended target is an ODrive v3-class device with M0 and M1 mechanically driving the same wheel axis. The current proposal is limited to FFBeast-compatible force-feedback input and controlled motor output, including an optional M1 torque contribution. No flashing or real-hardware operation is proposed as part of the current validation. Motor/encoder calibration, axis direction, current and torque limits, fault response, watchdog behavior, and safe-stop timing are unverified. The unknown checks in the supplied HEX are not to be bypassed as part of this proposal.

Options and tradeoffs

One candidate is to use upstream ODrive fw-v0.5.6 as a new base and add the FFBeast HID/control behavior; this provides a source-visible dual-axis implementation but is not a drop-in replacement and does not establish FFBeast parity. Another option is to keep device firmware outside REA and limit this repository to static analysis and host-only models. Maintainers may suggest a narrower boundary.

Verification available so far

I have a prototype or observed results. Host-only C++ build and CTest passed (1/1). There is no target ARM toolchain configured, no flashable custom image, and no real-device verification.

Success criteria and open questions

Record an explicit maintainer decision tied to the proposed final behavior and clarify whether this belongs in REA or a separate project. If allowed, identify required non-goals, target/authority boundaries, safe startup and stop conditions, handling of stale or malformed HID input and axis faults, M1 ratio and torque limits, hardware-less regression checks, and the real-hardware verification evidence required before integration. Current unknowns must remain explicit until verified.

References

Originally created by @h-oiwa-dseiko on GitHub (Oct 18, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5026 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion (search: “ODrive firmware motor”; no matches found). - [x] I understand the contribution scope must be reviewed before integration; open questions are welcome here. - [x] This discussion does not include credentials, private samples, or sensitive target data. ### Decision needed Does developing or hosting an ODrive v3 custom firmware in REA that accepts FFBeast-compatible USB force-feedback reports and commands motor outputs fit the contribution scope? The proposed extension includes using M1 to add torque to M0 on the same wheel axis. If this is in scope, what exact behavior boundaries and verification conditions must be met before integration? If it is out of scope, should the firmware remain in a separate project? ### Context and evidence The supplied FFBeast ODrive HEX has been statically inspected. Its target is consistent with STM32F405 / ODrive v3 hardware, and one PWM output path was traced. The analysis does not establish that the image drives M1, the physical torque/current conversion, or a verified watchdog and motor-stop path. The matching firmware source was not available. As source-derived evidence about a possible alternative base, public ODrive `fw-v0.5.6` v3 source constructs separate M0/M1 motor and encoder objects on TIM1/TIM8 and TIM3/TIM4. Its `INPUT_MODE_MIRROR` reads the selected axis's `torque_output_` and multiplies it by `torque_mirror_ratio` (default 0.0); it also mirrors position/velocity setpoints. This is not evidence that the supplied FFBeast image uses the feature or that a same-wheel setup is calibrated or safe. A host-only prototype models parts of the HID/effect behavior and a fail-closed M1 torque-mirror calculation. Its CTest suite passed, but no target firmware has been built or flashed and no motor or ODrive was operated. ### Expected interaction with targets Change process memory or registers. A running firmware would write motor-control/PWM registers and can physically actuate an attached wheel. No target interaction has occurred during the current prototype work. Network, persistence, and protection-bypass behavior are not proposed; the firmware's required startup, stop, timeout, and fault behavior still need review. ### Boundary details (optional) The intended target is an ODrive v3-class device with M0 and M1 mechanically driving the same wheel axis. The current proposal is limited to FFBeast-compatible force-feedback input and controlled motor output, including an optional M1 torque contribution. No flashing or real-hardware operation is proposed as part of the current validation. Motor/encoder calibration, axis direction, current and torque limits, fault response, watchdog behavior, and safe-stop timing are unverified. The unknown checks in the supplied HEX are not to be bypassed as part of this proposal. ### Options and tradeoffs One candidate is to use upstream ODrive `fw-v0.5.6` as a new base and add the FFBeast HID/control behavior; this provides a source-visible dual-axis implementation but is not a drop-in replacement and does not establish FFBeast parity. Another option is to keep device firmware outside REA and limit this repository to static analysis and host-only models. Maintainers may suggest a narrower boundary. ### Verification available so far I have a prototype or observed results. Host-only C++ build and CTest passed (1/1). There is no target ARM toolchain configured, no flashable custom image, and no real-device verification. ### Success criteria and open questions Record an explicit maintainer decision tied to the proposed final behavior and clarify whether this belongs in REA or a separate project. If allowed, identify required non-goals, target/authority boundaries, safe startup and stop conditions, handling of stale or malformed HID input and axis faults, M1 ratio and torque limits, hardware-less regression checks, and the real-hardware verification evidence required before integration. Current unknowns must remain explicit until verified. ### References - [REA contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) - [ODrive v0.5.6 v3 board mapping](https://github.com/odriverobotics/ODrive/blob/fw-v0.5.6/Firmware/Board/v3/board.cpp) - [ODrive v0.5.6 mirror configuration](https://github.com/odriverobotics/ODrive/blob/fw-v0.5.6/Firmware/MotorControl/controller.hpp) - [ODrive v0.5.6 mirror implementation](https://github.com/odriverobotics/ODrive/blob/fw-v0.5.6/Firmware/MotorControl/controller.cpp)

bsakaguchi closed this issue

2026-10-31 00:36:28 +00:00

bsakaguchi referenced this issue

2026-10-31 00:38:58 +00:00

[GH-ISSUE #5446] [Bug] Ambiguous provider selection offers providers already rejected as unconfigured #3304

bsakaguchi referenced this issue

2026-10-31 00:40:20 +00:00

[GH-ISSUE #5654] [Tracker] Open PRs that can't merge yet: conflicts and red CI (October 2026) #3425

bsakaguchi referenced this issue

2026-10-31 01:07:56 +00:00

[PR #3090] feat(providers): enable agent-aware deep provider selection #5607