Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ros1 imu backport #39

Closed
wants to merge 11 commits into from
Closed

Conversation

idlebear
Copy link

Hi there -- sorry if I'm stepping on any toes, but I needed to get IMU data for the vesc running against a TX2.

Completed a backport, basically pulling from the ROS2 branch as necessary. Preliminary testing looks good, on Melodic/18.02, though I only have a sample set of one.

I've got a few other minor adjustments I've had to make to quiet down a few warnings, but they're all in another branch. I'll do another pull req if you want them too.

Where possible, I tried to retain formatting, but it appears my autoformatter has made some white spaces changes here and there. Do you have a preferred formatter?

Updated from the current tip in ROS2 branch, primarily to enable IMU data in older systems.  Testing required.
Resolves frequent timestamp errors that were occurring
For certain custom cars, the servo is flipped -- exposed a config param
Necessary to prevent robot_pose_ekf from complaining 
about zero covariances
@JWhitleyWork
Copy link
Collaborator

Changes seem pretty simple. Will merge if CI passes.

@idlebear
Copy link
Author

It was a fairly straightforward port. I've made some other minor changes since to make it play nice with some of the ROS1 eco-system, some more necessary than others:

  • a default IMU frame, with rosparam init -- quiet error message and allow for static TF
  • default (high) variance for unmeasured/reported poses -- robot_pose_ekf didn't work with null values
  • shortened message queues as old data was causing some issues (may not be necessary)
  • invert Y on servo - allows reverse of server operation (probably needs a better name)

I haven't submitted any of these -- let me know if you think they're useful and I'll submit a follow-up pull

@idlebear
Copy link
Author

idlebear commented Nov 5, 2023

Maybe hold that thought -- besides the build issue, there's another performance issue that these changes are causing. After a short interval (minutes of operation), the VESC stops responding to RPM requests. I'll reopen this request once I figure out what's going on.

@idlebear idlebear closed this Nov 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants