Unchanging Angular Position at low yaw rates; delayed information at high yaw rates

[L Roberts]

I am processing data from a Hillcrest FSM-USB-2 [is this identical to the newer FSM-6?].

At yaw rates of 0.2 degrees per second over several minutes, totaling 90 degrees of turn,, the module shows no change in orientation.  

Additionally, with reversals of direction of motion, the change of sign of the angular velocity lags around a second.

These two problems cause instability in my motion control application.

Is there any way to correct this and see the small motions and the reversals of direction  ... such as using the "angular velocity error" available in the motion engine output?  Do motion reports queue up such that when I read the Hillcrest device every 1/8 second or so, I am getting old queued up information? If so, how do I avoid this?

[Merrill]

Thanks for the question.

There is a minimum velocity of motion that can be tracked by the FSM-USB-2 (aka FSM-6).  This is tied to the performance of the sensors used on the module.  I believe it is ~0.02 rad/s which translates to ~1.1 deg/s.  For roll and pitch, we can use gravity to get an accurate estimate of the orientation even if the dynamic motion was not tracked.  However, for yaw we do not have an absolute reference source on the 6-axis module.

We are close to releasing a 9-axis variant which should track these yaw orientation changes much more accurately due to the addition of a magnetometer and our dynamic mag calibration algorithms.

Regarding your question about queuing, we only output the most recent data.  If you are reading the data at 125 Hz then you are getting the latest data that the module has to offer.

Thanks,

-Merrill

libfreespace moderator

[L Roberts]

Thanks for your help ... I subsequently read the sensor repeatedly until I got a timeout error at 5ms [indicating no more data available] rather than success.  I then used the data from the most recent read.  That eliminated the delay problem completely.  It seems that there is buffering somewhere - I guess just not in the sensor itself.