OK, I'll admit I'm a bit of a cheap skate. I've been happily using a yaw rate gyro into one of the channels on my DL-1 since I first got it (my serial number is just into 3 figures), and don't really want to spend the money for the all singing and dancing drift angle measuring version.
Just thinking aloud here - if I wrote an interface program that read the data stream and when it found the analog channel of note, added an entry to the internal channel for the yaw rate to the data stream, would that enable drift angle measurement within the Analysis program.
It'd solve another problem as well in that I'd be able to refer to Yaw Rate as a channel (as I always used to do) without the program sulking about duplicate channel names.
Yaw Rate Sensor...
-
DaveTurner
- Posts: 34
- Joined: Sun Nov 20, 2005 6:21 am
-
DaveTurner
- Posts: 34
- Joined: Sun Nov 20, 2005 6:21 am
Yaw from affordable rate gyros is not very accurate.
Perhaps you have seen, as I have, surprisingly good raw data that only has very slow drift of the DC offset, which on the face of it integrates quite well.
Unfortunately, taking the next step, comparing this to the change of heading or path curvature, etc. too often results in glitches that don't properly fit the vehicle motion from video evidence, for instance, sometimes being of the opposite sign. The magnitude is almost always somewhat suspect.
Nevertheless, the data has value, as for a reasonable proportion of cornering events it fits quite well and it is tempting to believe remains proportional to the real yaw. By inspection, it is not too hard to apply manual corrections, but I have yet to devise a satisfactory algorithm to automate the process. R-T's early attempts were pretty woefull, but they are aware of this and strive to improve. There is at least one Revision note to this effect.
I have seen good and bad raw data from MEMS devices. In the good examples, thermal drift was still an issue but I have yet to create a satisfactory algorithm for this, but I'm using in car logs rather than bench tests...
R-T should be able to characterise their units better so I am not casting aspertions on the quality of their DL1 option. Nevertheless, we should bear in mind that drift in the R-T DL1 sense is as in "Drifting" rather than a fine vehicle dynamics measurement. They have other devices more suitable (and expensive) for that purpose.
Perhaps you have seen, as I have, surprisingly good raw data that only has very slow drift of the DC offset, which on the face of it integrates quite well.
Unfortunately, taking the next step, comparing this to the change of heading or path curvature, etc. too often results in glitches that don't properly fit the vehicle motion from video evidence, for instance, sometimes being of the opposite sign. The magnitude is almost always somewhat suspect.
Nevertheless, the data has value, as for a reasonable proportion of cornering events it fits quite well and it is tempting to believe remains proportional to the real yaw. By inspection, it is not too hard to apply manual corrections, but I have yet to devise a satisfactory algorithm to automate the process. R-T's early attempts were pretty woefull, but they are aware of this and strive to improve. There is at least one Revision note to this effect.
I have seen good and bad raw data from MEMS devices. In the good examples, thermal drift was still an issue but I have yet to create a satisfactory algorithm for this, but I'm using in car logs rather than bench tests...
R-T should be able to characterise their units better so I am not casting aspertions on the quality of their DL1 option. Nevertheless, we should bear in mind that drift in the R-T DL1 sense is as in "Drifting" rather than a fine vehicle dynamics measurement. They have other devices more suitable (and expensive) for that purpose.
Return to “General support questions”
Who is online
Users browsing this forum: No registered users and 13 guests
