WIP: CORE-36183: [puma motor driver] CAN adaptor implementation #291
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.
This PR implements the puma motor drivers using HAL CAN adaptors.
In the context of the puma drivers the
Driverclass is a HALSignalAdaptorresponsible for mapping signals to and from the device. TheMultiPumaNodeis just initialising 4 adaptors.HAL Concepts
HAL supports cyclic and acyclic data. That is: streaming data, and data on request.
The implementation of this varies between protocols. For CAN this uses RTR frames.
Puma Concepts
The puma driver statemachine is effectively: configure, verify, run.
out of the box the CAN adaptor doesn't support this, so we can't move to pure configs just yet.
The protocol used by the pumas as a request data mechanism similar to RTR frame (though it doesn't set the RTR flag).
Changes
First off all the signal registration now happens upfront (CAN IDs and data type). previously you'd have to look at where the CAN IDs were used to understand the data types.
Part of the fixed point float conversion is now managed automatically by the adaptor.
Support was added in the CAN adaptor to override the request read frames. In the context the pumas, this is clearing the RTR flag.
A puma specific signal type was added to wrap the adaptor and add better semantics around interacting with the signals. This is a feature I'd like to add to the core eventually.
Future work
Generalisation of the state machine can be done to enable implementation without bespoke code.
Once ros2_control support is added to hal we can map signals to joints from the urdf.