Controller handling different input types

[dylan-gonzalez]

I have a use case where I want to have a four wheel steering controller. I was planning to write a new one and adapt it off of the tricycle steering controller. My problem is that my use case has an autonomous mode which uses nav2 to output a Twist command, and a manual mode which outputs a linear velocity and turning radius. The problem is that I can't think of a clean way for my controller to handle both of these modes (only one mode will be activated at a time) because they each have different topic types.

I've tried thinking about whether I could use a ros service to listen to autonomous mode and switch to listening to a Twist command, or dynamic parameter change. But honestly not too sure.

I've also considered chaining an Ackerman four wheel steering base controller with an Autonomous mode controller and manual mode controller to each handle their different topics.

I contemplated propagating the turning radius from manual mode through a Twist message (but this is ugly), and vice versa for autonomous mode with an Ackerman drive message.

The use case is a four wheel Rover with four drive motors and four pivot motors.

[christophfroehlich]

Why don't you use two different controllers, and switch them depending on your control mode? Like we do it in example_1?

[dylan-gonzalez]

Can I extend the steering_controllers_library to handle AckermannDrive msg types as well? Right now it seems that it only handles Twist messages

Although I'm a bit confused because in the header file they have a ref_subscriber_ackermann_ but it's of type ControllerTwistReferenceMsg ?

[christophfroehlich]

Can I extend the steering_controllers_library to handle AckermannDrive msg types as well? Right now it seems that it only handles Twist messages

What do @destogl or @bmagyar think about that?

Although I'm a bit confused because in the header file they have a ref_subscriber_ackermann_ but it's of type ControllerTwistReferenceMsg ?

This is a bit misleading and will be fixed with #836

[github-actions]

This issue is being labeled as stale because it has been open 45 days with no activity. It will be automatically closed after another 45 days without follow-ups.

[christophfroehlich]

@dylan-gonzalez have you found a solution back then? In the meantime there exists a PR which implements what you were asking for, could you please test it in case it is still relevant for you?