Closed dani-carbonell closed 8 years ago
Would probably make sense to have a separate node binary to mux ackermann topics, but there's a bunch of logic here (diagnostics, markers, etc) that would be applicable to both or could be easily generalized to be so.
Some classes are templated, so you can easily extend them and create a new nodes that works with ackermann_msgs
. I have to look into this msgs and some robot using it to understand why a twist
msg isn't enough for you, or whether a conversion is possible or not. I guess you can still have twist inputs and convert the output from Twist
to AckermannDrive
.
That Twist
to AckermannDrive
"conversion"/interpretation is what an Ackermann-controller would do, at least in my world (unless you have direct AckermannDrive_msgs commands ready from a steering wheel-type device).
@dani-carbonell any update on this? What do you think about @bmagyar 's comment?
Closing since this is quite old now, and there's no activity here.
Furthermore, IMHO, @bmagyar comments stands.
Hi! I have been using this package already for a while and it works really good. Now I need a similar package but to be used with "ackermann_msgs". Is there any chance this package gets upgraded to be compatible with this kind of messages? Or should we create "ackermann_mux"?
Thanks! :)