Page 1 of 1

Discrepancy between commanded and actual turn rate

Posted: Tue Sep 10, 2013 3:36 pm
by ChrisC
When commanding the RMP440 Flex Omni platform to turn in place, we’re seeing a discrepancy between the commanded turn rate and the actual turn rate of about 20 degrees at an update rate of 10hz (the discrepancy between commanded and observed linear movement is near zero). Obviously, this kind of discrepancy makes SLAM or any other reconstruction algorithm nearly impossible onboard the vehicle. Additionally, the vehicle cannot follow plans that require any kind of turning.

Please advise.

Re: Discrepancy between commanded and actual turn rate

Posted: Wed Sep 11, 2013 9:35 am
by sdnalloh
Have you looked at the values for these two feedback variables?
  • inertial_z_rate_rps
  • pse_yaw_rate_dps
Both of these variables are derived from the inertial estimates of the Balance Sensor Assembly (BSA) and should be fairly accurate.

Re: Discrepancy between commanded and actual turn rate

Posted: Wed Sep 11, 2013 5:51 pm
by phussey
I think the issue they are experiencing is that the physical orientation of the platform in pure yaw motion for a period of time does not match the integrated yaw rate command over the same period of time. Which would imply that something is going on physically with the machine (ie increased roller friction due to bent wheels), the time period they are measuring is very long and the error accumulated is normal for dead reckoning techniques or there is something wrong with the gp params which resulted in the error.

Could you please provide some detail of how you arrived at the results ie:

Normalized yaw command,
Yaw rate limit,
Yaw acceleration limit,
Duration of command,
Measured orientation relative to start.

We will also perform some testing this week to verify it is not a bug.

Re: Discrepancy between commanded and actual turn rate

Posted: Fri Sep 13, 2013 3:17 pm
by phussey
We have completed the testing and verified that there is infact no bug. I can reproduce what you are experiencing by incorrectly setting the yaw accleration rate in the configurable parameters.

By default the yaw acceleration limit is 1 rad/s^2. This means that a command of 1 rad/s will take 1 second to ramp to the full command.

For example:

yaw_accel_limit = 1.0 rad/s^2
yaw_cmd = 1 rad/s
Time duration= 1s

Angle orientation based on integrated rate limited yaw command (the one applied in the controller):
0.515 rad = 29deg

Angle orientation based on integrated input command (the one issued by the user stepwise):
1 rad = 58deg

So the delta would be ~28deg between the user issued command and the rate limited command applied in the controller.

The reason for the yaw acceleration limit is to reduce the sensitivity of the tele-operation controls. For autonomous applications where the external controllers manage the input continuity, the yaw acceleration can be set to the maximum. This also applies to the linear acceleration and deceleration limits. Caution needs to be taken because all command rate limiting will essentially be removed and only limited by the motor constants.

The max limits for the OMNI platform:


At a minimum to fix your issue please set max yaw accel limit (RMP_CMD_SET_MAXIMUM_TURN_ACCEL = 7) to the max (28.274 rad/s^2)