[cob_omni_drive_controller] Add configuration options for DiffDriveController

[fmessmer]

separating this from #62

(Dynamic reconfigure is interesting for the controller settings..) (@ipa-mdl)

[fmessmer]

Looking into this...am I missing something?

For the bases that already use the diff_drive_controller (as well as for simulation), in the base_controller.yaml files, the max_rot_velocity and max_trans_velocity are commented and thus not set (e.g. here) and thus default to 0.0 - how can we actually drive then?

ANSWER:
Ok, if limit is 0.0, we do not limit - is this really desired? Why are the limits commented in the yamls?

[fmessmer]

Maybe we could also start gathering a list of the parameters that should be made dynamically reconfigurable...@ipa-mdl @ipa-mig (and Nav-Team) please provide input...

[mathias-luedtke]

Why are the limits commented in the yamls?

To move as fast as possible? ;)
Do we have to limit it?
Update: it is just a limit for the input.

[mathias-luedtke]

gathering a list of the parameters that should be made dynamically reconfigurable...

Limits:

• max_rot_velocity (input limit)
• max_trans_velocity (input limit)
• max_steer_rate (output limit)
• max_drive_rate (output limit)

Params for the steer controller (could be even set per steer axis):

• spring
• damp
• virt_mass
• d_phi_max
• dd_phi_max

I am not sure if we really need to set these dynamically.

[mgruhler]

Why are the limits commented in the yamls?

To move as fast as possible? ;)
Do we have to limit it?
Update: it is just a limit for the input.

Well, from my point of view, it is absolutely crucial to limit the output to reasonable values.

Having no limit on the input is okay for me. But it might make sense to throw a warning, if it is something enormous (e.g. 5.0 m/s is something which we will not command, ever, to a service robot base), pointing to a bug in the node generating the commands. Thus having a high default for the input limits would be beneficial.

Also, from my perspective and in general:
-1 for making limits dynamic reconfigurable
+1 for making controller variables dynamic reconfigurable

[mathias-luedtke]

Well, from my point of view, it is absolutely crucial to limit the output to reasonable values.

This is just the old controller implementation. Feel free to extend limiting wherever you need it.

[mgruhler]

• max_steer_rate (output limit)
• max_drive_rate (output limit)

From this, I expected the output is already limited? So I'm happy there ;-)
This was just to give the full picture...

[fmessmer]

As I see it, both input (max_rot_velocity, max_trans_velocity) and output (max_steer_rate, max_drive_rate) limits are currently nowhere set within the yamls...thus defaulting to 0.0...thus not limiting neither input nor output!

I guess then the only limit is encoded within the Elmo firmware for the individual driver, no?

However, I think the base_velocity_smoother and (maybe) even the twist_mux limit the incoming Twist command...

[fmessmer]

Also, the structure of the yaml parser (with parsing the defaults parameter tag) is not that easy to combine with the dynamic_reconfigure concept (operating on explicit parameter server namespaces)...(or I simply didn't fully get the templated-concept...)...so "wheel-wise" configuration seems complicated...

Also, it seems that currently there are no set() functions for the CtrlParams that dynamic reconfigure could use to set new values for e.g. spring...would reseting the Controller be the right way to do this?

[fmessmer]

Not directly related to configurability, but likely related to configuration:

I don't know whether the behavior was similar before, but since switching to using the ros_canopen-based driver with the "old" cob4-2 platform, I observed some oscillation on the robot (to be seen in the odometry topic)...that even "sways" the whole upper body (torso) a bit...(see plots below!)

Questions:

1. Has this behavior been observed before switching to ros_canopen? Mabe even on the raw's?
2. Has any configuration in the Elmo firmware been modified?
3. Can we be sure, the implementation of the controller is the same? If not, what has changed?
4. Can we be sure, the configuration of the controller is the same as with the old undercarriage_ctrl? Have all parameters from the "Ini-Files" been moved/are considered in from the yamls/have reasonable defaults? Which of the parameters have not been ported - but are possibly crucial?

Additional - here is a plot together with the according joystick commands:

I will also create a plot circumpassing the velocity_smoother by publishing a sine Twist diretly to the base once the robot is free to use again...

[fmessmer]

Here is the promised test run publishing a sine signal to the angular/z component of the /base/twist_controller/command topic (no smoother involved!):

50Hz

[fmessmer]

After quick discussion with @ipa-mdl, also plot (on cob4-1):

• odometry/pose
• base/joint_states

Compare behavior on raw (old Elmos + old undercarriage_ctrl)
Unfortunately, we do not have a cob4-3/4/6 (new Elmo + control_plugin) anymore and cob4-1 with old Elmos and old undercarriage_ctrl requires hardware modification.

P.S.
On a first glance, we saw the velocity of the fl_caster_r_wheel_joint and fr_caster_r_wheel_joint oscilate a bit. This is only due to 10kHz interval....the oscillation cannot be seen in the respective joint's position!
Might require some Elmo tuning or "smoothing" á la torso_driver.yaml

[fmessmer]

Step response of base to an angular/z exictation 0.0 -> 1.0:

[fmessmer]

Discussion about base behavior after switching to new ros_canopen (starting in this comment) has been answered and solved in #98

[fmessmer]

Coming back - after the "UM 2 excursus" - to the main discussion of this issue, i.e. (re-)configurability and limiting within the base_twist_controller:
Here is a detailed summary of current limiting behavior: https://github.com/ipa320/cob_control/issues/92#issuecomment-279648573

[fmessmer]

Dynamic reconfigure for the default values of the SteerCtrl parameters, i.e. applied to all wheels, is implemented in #135

[fmessmer]

Plot Alarm

Here are some plots using current (cob_control/cob_robots) ipa320/indigo_dev implementation/configuration using the test scripts provided in #134 performed in gazebo simulation:
(Commands are published directly on /base/twist_controller/command, i.e. no twist_mux, no velocity_smoother involved!)

Step Response

1. Step Linear (wheels oriented in linear direction)
   
2. Step Linear (wheels oriented in rotational direction)
   
3. Step Rotation (wheels oriented in rotational direction)
   
4. Step Rotation (wheels oriented in linear direction)
   

Sine Response (input publish frequency 10Hz)

1. Sine Linear (wheels oriented in linear direction)
   
2. Sine Linear (wheels oriented in rotational direction)
   
3. Sine Rotation (wheels oriented in rotational direction)
   
4. Sine Rotation (wheels oriented in linear direction)
   

Sine Response (input publish frequency 50Hz)

2. Sine Linear (wheels oriented in rotational direction)
   
3. Sine Rotation (wheels oriented in linear direction)
   

[fmessmer]

Some observations and more detailed analysis:

Positioning of Steer Drives

To position the steer drives from a rotational direction to a linear direction or from a linear direction to a rotational direction, currently takes about 0.5 seconds. And leads to a slight jolt in the odometry.
1.Rotational to Linear


2. Linear to Rotational

I think the steer drives could/should both react a bit faster and level out a bit faster, by tuning the SteerCtrl parameters

Impact of Input publish frequency

For low frequency input, the input vs. odometry looks quite jerky...

1. Input frequency 10Hz
   
2. Input frequency 50Hz
   

[fmessmer]

configurability is added in #141

[fmessmer]

closing this issue as #141 is merged

further activities and consequences, e.g. tuned default parameter, can be discussed in #143