[cob_omni_drive_controller] Insights and findings from steer behavior tests

[fmessmer]

This is a detailed summary of the investigations performed last week - on cob4-8 hardware:
(For previous investigations in simulation see here)

Main objectives:

• investigate behaviour of drive and steer joints individually
• investigate behaviour of joints when commanded by omni_drive_controller
• in order to identify potential for optimization of reactivity of controller
• in order to identify potential for optimization of accuracy of controller

Current controller implementation/configuration results in e.g. the following step response showing

• input Cartesian twist + resulting odometry (center)
• drive joint target velocities + drive joint velocities (left)
• steer joint target velocities + steer joint target error (right)

Note that currently both drive and steer joints are commanded in VelocityMode using the Mass-Spring-Damper-Control algorithm with fixed parameters (from yaml).

The reaction of the steer joints is of particular interest:

It can be seen that the steer joints require about ~1.0 sec for reaching the target steer position (i.e. target veloctiy == 0.0 again) with a significant velocity ramp on initial stimulus and overshoot/oscilation (steer_target_velocity[1]).

The initial ramp is due to cut-off limitation of steer drive acceleration.
There also is a joint-specific cut-off limitation of the steer drive velocity. This might lead to non-coordinated movement of the wheels. Which might lead to wear on the base frame.

With #91 and #140, experiments were performed in order to optimize controller behavior by modifying/tuning control parameters:
First the controller-internal acceleration/velocity limitation has been disabled. This leads to a quicker reaction after receiving an input stimulus:

Still there is significant overshoot and settle time is still about 1.0 sec.

Note there still is an acceleration/velocity limitation within the Elmo controller itself which can be seen in the following plot (graphs with dots depict joint_states). It can be seen that target velocities are un-limited (in left plot) while measured joint_states shows a limitation.

Experimental modifications (i.e. without proper system identification and control engineering expertise) of mass, spring and damping parameters did not lead to a significantly better behavior (oscillation/escalation of steer joints).

Another interesting effect of the velocity-controlled steer joints is depicted in the following plot:

It clearly shows a steer-position-dependend, 360°-periodic velocity noise (joint velocity command vs. joint velocity) in the magnitude of about +/-0.5 rad/sec.

As steer joints are not designed/proportioned/configured for velocity control, position mode for the steer joint has been tested as well. Position mode shows much better accuracy and reactivity as well as less noise in the sensor data.
This is well worth further investigation...

Available new features of ros_control (from Jade onwords, because API-changing) allow the implementation of multiple/mixed interfaces within a single controller. Thus a controller is proposed in #140 for Kinetic using position-controlled steer joints and velocity-controlled drive joints.
More on this in a separate issue #144

@ipa-mdl @ipa-fmw @ipa-mig @ipa-bnm @ipa-flg @ipa-tif @ipa-nhg @fmessmer FYI
Please leave comments/suggestions/questions 😉

[timhappy]

Great summary Felix!
The Noise in the last picture is unclear to me, we can go hunting it togther but I'm sure Elmo isn't sendig this noise. Otherwise a control would not be possible. The graph looks like a wrong sampling e.g. from a buffer.

As already stated out a speparation of controlers is needed. The mass-spring-damper-system is a plant for an open position control loop. That is not needed anymore because the elmo has a good tuned closed position loop. After erasing this from the wheel multi controller there should be left "only" the solving of the inverse kinematic problem, at least in my understanding. There should no control loop be inside to avoid frequenzy dependant phaseshifts that lead to instability.
CPCs approach included the position loop because its mistly based on velocities - as far as I remember. Couldn't a general solver for parallel kinematics help us?