detecting slowly developing yaw rates

[L Roberts]

My application uses a Hillcrest FSM-6 sensor wired to a Raspberry Pi by USB cable.  The Raspberry Pi is programmed in 'C' running under the Linux OS.  I am using sensed yaw rates and GPS outputs to provide stabilized heading information when the magnetic compass is unreliable.

The FSM-6 is reliably detecting large yaw rates and producing accurate heading information in large turns but fails to detect slowly developing yaws and often reports cessation of yaw as a yaw rate reversal.  The small yaw rates that are being unreliably detected are nonetheless well in excess of the stated 0.06 deg/sec stated resolution of the FSM-6.  I have solved some earlier problems in my software by now extracting information from the FSM-6 at 125 Hz.

My questions are:

1. Are slowly developing small yaw rates 'biased' out somehow assuming them to be sensor errors?  If this is the case, is raw sensor information available via the USB port?

2. Is the yaw rate sensor subject to influences other than yaw?  For instance, does lateral or longitudinal acceleration output erroneously as a yaw rate?

Thanks for any ideas you can offer in extracting better performance from the device.

Larry Roberts

[Merrill]

Hi Larry,

Thanks for the question.

The behavior you are seeing is likely an effect of the gyro's changing Zero Rate Offset (ZRO).  The ZRO is basically the value that the gyro outputs when at rest.  MEMS gyros have a natural tendency to be affected by small temperature changes such that their ZRO value fluctuates during normal use (also affected by aging).  What this means is that it is very difficult to distinguish small rotations from gyro ZRO changes due to temperature.  We have an algorithm that dynamically tracks the ZRO based on temperature and motion data from the accel, but it is not perfect in yaw rotation.

The yaw rate reversal you are seeing could be explained by our algorithm mistaking your slow constant yaw motion as a ZRO change and thus cancelling it out.  When you stop the rotation the algorithm considers this a rotation in the opposite direction and thus reports a negative yaw rotation.  This kind of behavior should not last long as the device should quickly converge on the more accurate ZRO.

It is possible to get raw sensor data from the module, but this will not contain any of our ZRO estimates nor any of our device calibration information that we compute when each module is produced.  This means that scale, skew, and rotation will also be inaccurate if you do not use our calibrated outputs as you are now.

Regarding other factors that affect the gyro, there is some coupling to the linear acceleration but this is part of the individual device calibration that we perform in our factory as well.

So in summary, unfortunately with consumer-grade MEMS sensors it is very difficult to accurately detect very small and constant yaw rotation.  Let me know if I can answer any other questions.  Thanks.

-Merrill

libfreespace moderator

[L Roberts]

Thanks for the quick reply ...

Can you advise me what message I would send to the module to get it to output raw sensor data to me and the format of the resulting message it will send me.  I am not sure in advance that I will like the results but I would like to try it.  As I am generating my own yaw corrections from a GPS output, I suspect a ZRO or scale error will affect me less than the possible artifacts from the ZRO algorithm [like yaw reversal] that I am seeing in my application.

As an aside, your 9 axis module will probably not help me as I plan to use the device in the High Arctic where the earth's magnetic field is a poor indicator of direction.

Thanks for any help you can offer.

Larry Roberts

[L Roberts]

... and one additional question ...

In an environment where motion is more or less continuous, is your ZRO algorithm likely to yield better results after the module has been powered up for a long period of time [days]?

Thanks

On Monday, April 29, 2013 8:07:52 PM UTC+1, Merrill wrote:

[Merrill]

Hi Larry,

No problem.  Are you using libfreespace (over USB) or are you communicating over SPI?  It is possible to read this raw sensor data using libfreespace, but we did not include a direct parser of this raw sensor data message so it will take a little extra work.  Here are some instructions:

The raw sensor message is known as SDA (Sensor Direct Access).  You can put the module into this mode using the Data Mode Control V2 Request message.  Set PacketSelect = 6 to set this data type.  Now, the module will output in SDA mode.  The challenge with libfreespace is that there is no way to directly parse this message using the library.  You can read the HID message directly and parse it manually.  I've attached the message format definition (A is for accel, R is for the gyro (rotation), Rtemp is the temp from the gyro)

If you are using SPI then you can do the same process.  Send a DataModeControlV2 Requeset message with PacketSelect = 6 and read an SDA Message using the format below.

I'm sorry that there is not an easier way to read these raw messages - we did not intend for this data to be used publicly but I understand your thoughts about how it might be useful for your app so hopefully this works for you.

Regarding your question about ZRO if the device is powered on for a long period of time, I doubt that you would see any difference.  Our algorithm converges on the new ZRO pretty quickly.  The ZRO is affected by time, but it is a very gradual process and our algorithm compensates for it dynamically.

Hope this helps, but let me know if you have further questions.  Thanks.

-Merrill

libfreespace moderator

[L Roberts]

Hi Merrill,

Thanks for the information on obtaining the raw sensor outputs.  I have now had the opportunity to do some tests in relatively calm water and the previous heading instability problems are gone.  I will, in the next week or two conduct some tests in rough water with the attendant random pitch and roll and see how that works out.

I wouldn't want to draw any general conclusions about your firmware as I expect it is optimized for most of your users applications.  All that comes to mind is perhaps using a longer time period to find the ZRO in yaw or perhaps allow the user to turn off the ZRO in yaw.  I found the pitch and roll information useful but since I am using SDA, will have to code the ZRO for those myself.

Thanks again for your help ... I am very pleased with the results I am getting now!

B.T.W ... I am using the USB interface - The Raspberry Pi does support SPI but USB is trivial to wire up.

[Merrill]

Hi Larry,

Great to hear that you got it up and running!  I'll pass your suggestion about a user configurable ZRO config to our product guys.

Let me know if you have any other questions.  Thanks.

-Merrill