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

[Feature] Add Odometry messages to view plots of pose/speed #9

Open
SteveMacenski opened this issue Apr 7, 2019 · 4 comments
Open

Comments

@SteveMacenski
Copy link

May help in debugging EKFs or generally just odometry messages from encoders in a base. I will keep this in the back of my mind to implement if I have the cycles but wanted to get out in writing if I don't happen to get to it.

@dheera
Copy link
Owner

dheera commented Apr 11, 2019

Yup implementing Odometry, Trajectory, Path, are all on my wish list too. :) Maybe I'll implement a minimal version and then people can make suggestions on what's actually useful.

@SteveMacenski
Copy link
Author

I was thinking of an ascii wheel rotating proportional to speed with all the data next to it to be fun :)

@dheera
Copy link
Owner

dheera commented Apr 17, 2019

I've added initial support for Odometry messages. It currently only displays 2D Odometry for now (sorry drone users...). I'm thinking about how to best auto-center/auto-scale/auto-pan without being annoying. Currently it just centers to the first message received and doesn't auto-pan.

It also displays only the Pose and not the Twist. Your idea of an ascii wheel is quite interesting! I'll definitely think about some form of visualization of the Twist as well. The only issue with a rotating wheel is the frame rate is limited when used over a slow bandwidth SSH connection, so it may not be as easy to discern what the speed is in a useful way. Thoughts?

@SteveMacenski
Copy link
Author

Oh, I didnt think it would be useful at all, I just figured it'd be cute. Then putting the speed below the wheel as the actual thing of use. This all relative to what's slow or fast but it made more sense to me than a status bar because the range on that is dependent on application. But a wheel spinning people for different applications would get an intuition of how fast it should be for what they're used to without having to place a strict limit or asking for a range

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

No branches or pull requests

2 participants