Initial positions are set to 0 causing sudden movement#67
Initial positions are set to 0 causing sudden movement#67daniel-kovari wants to merge 4 commits intoenactic:mainfrom
Conversation
daniel-kovari
changed the title
|
Will test on the hardware!! Thanks |
ggorjup
left a comment
ggorjup
left a comment
There was a problem hiding this comment.
I tested this on real hardware and it seems to work fine.
In case it's useful, I'm suggesting a couple of simplifications.
There was a problem hiding this comment.
Thanks for the work!
Could v10_hardware.cpp go into a separate PR? This looks unrelated to the zero-position issue.
There was a problem hiding this comment.
Hi, I cleaned up the PR. I moved the changes for gravity compensation onto another feature branch: https://github.com/Kovari-Industries/openarm_ros2/tree/feat/gravity-compensation. It is using a KDL chain and implying the urdf from the controller manager - HardwareInfo::original_xml. This works for me and makes the controls much smoother. If this is a valid implementation, I can put that up as a separate PR.
There was a problem hiding this comment.
Thanks for splitting that out. It's much cleaner to review now.
Gravity compensation is something we're interested in as well, so please feel free to open it as a separate PR.
We can discuss the design (KDL chain, reading URDF via HardwareInfo::original_xml, etc.) over there.
| "Setting current position..."); | ||
|
|
||
| // Use read() to populate state arrays | ||
| read(rclcpp::Time(), rclcpp::Duration(0, 0)); |
There was a problem hiding this comment.
What if CAN communication fails? Won't pos_states_ be left holding a stale or default value after read()?
Would it make sense to add a safety check?
4 participants
Fixes #66