General Sensor Model now runs in automatic mode
cessnapilot
Posts: 182
Hi,
The previous version of the General Sensor Model at OBEX (http://obex.parallax.com/objects/464/) with hand-recording and hand-typing has been replaced. The object is now a menu-driven boot EEPROM datalogging application, where all operations are full automatic. A complete calibration of a H48C takes only 10-15 minutes with 30 steady poses. Even the results improved. (Well, a simple bug was removed from the parameter optimizer.)
Original accuracy, without calibration·is about 50 mg (one standard deviation).
Measured accuracy for 5 H48C after calibration with the new object:
Sensor······· Std Error in mg······· ·· Selected
· A·················· 0.8· ---->······· For 6DOF IMU
· B·················· 0.6· ---->······· For 6DOF IMU·
· C·················· 0.7· ---->······· For 6DOF IMU
· D·················· 0.7· ---->······· For 6DOF IMU
· E·················· 0.9· ---->·· For Magneto/Gravito AHRS
As a bonus, you can find· in the package a 64K/32K System Boot EEPROM driver (of 82 LONGs) with device checking.·
Cheers,
istvan
The previous version of the General Sensor Model at OBEX (http://obex.parallax.com/objects/464/) with hand-recording and hand-typing has been replaced. The object is now a menu-driven boot EEPROM datalogging application, where all operations are full automatic. A complete calibration of a H48C takes only 10-15 minutes with 30 steady poses. Even the results improved. (Well, a simple bug was removed from the parameter optimizer.)
Original accuracy, without calibration·is about 50 mg (one standard deviation).
Measured accuracy for 5 H48C after calibration with the new object:
Sensor······· Std Error in mg······· ·· Selected
· A·················· 0.8· ---->······· For 6DOF IMU
· B·················· 0.6· ---->······· For 6DOF IMU·
· C·················· 0.7· ---->······· For 6DOF IMU
· D·················· 0.7· ---->······· For 6DOF IMU
· E·················· 0.9· ---->·· For Magneto/Gravito AHRS
As a bonus, you can find· in the package a 64K/32K System Boot EEPROM driver (of 82 LONGs) with device checking.·
Cheers,
istvan
Comments
what are you using this for? Do you have a link to an explainer perhaps?
thanks
CRP
(as in turbo-props [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If I understand correctly, this could be used to combine multiple sensors (accelerometer, gyro, magnetometer) to get a good 6DOF reading (with hard/soft iron correction and temperature compensation)? How does the temperature compensation work? Does it need a temperature sensor, or does it determine the temp correction needed from the drift in readings? Also, I see it uses the uM-FPU, but you say it's not needed... how easily portable is it to the Prop FP libraries?
Speficic questions to my hardware... I assume it could be converted to work with a Wii Nunchuck accelerometer and MotionPlus gyro? How about the MicroMag3 (www.sparkfun.com/commerce/product_info.php?products_id=244)? It's not really a MEMS sensor, but I assume your object isn't really specific to MEMS.
Slightly off topic... I see you use that uM-FPU in several of your objects... does that work well? I've considered trying it out, but my impression of it was that it would be great for a slow uC, but something like the prop could do FP in software well enough that the speed improvement wouldn't be great.
DogP
I am using this to improve the accuracy and the precision of some MEMS sensors 20-50 fold, including some of those that are sold by Parallax. Accuracy and precision count sometimes.
Some explanation you can find in the "6DOFIMU with only.."· thread. Check the "GPS_IMU_MAGN.PDF".
istvan (CP)
The temperature compensation used in the 464 object does its job only by software. The driver senses stabilized, constant speed motion, averages readings for a while, checks g magnitude and adjusts factors accordingly. Interesting thing is, that after homogenizing and squaring axes with the General Sensor Model math, only one temp. corr. factor is sufficient to keep spherical response. I noticed this for a HM55B(2x) array, as well.
For rate gyros, you have to provide "constan size reference rotations", instead of g.· For this I am using a small wise mounted axially on a Sherline Rotary Table with stepper motor. The drift of an ADIS16100(3x) rate gyro array, and the cross- talk effects of axis misalignments could be decreased significantly with the General Sensor Model, but only at a given temperature! In-situ temperature stabilization, or series of calibrations at different temperatures can help.
As for me, the stabilization of the temperature of these MEMS·gyros with a small Peltier cell / metal block heat reservoir combination seems more reliable. That can be realized for the ADIS16100(3x) SMD chips with a small copper cube, and a Peltier cell on the 4th side, a DS1621 on the 5th, although these gyros have temperature output. The mounting can be done using 6th side of the cube and/or the other side of the Peltier cell. This other side of the Peltier cell should be pressed to a heat sink. And, of course a Propeller with the General Sensor Model should be there to control all these. A less than cubic inch, thermostated, high precision 3-axis gyro can be built. This is closing, although not (yet) reaching laser quality (inferred from the constant temperature results with the Prop/GSM), but with only a very small fraction of the price.
I do not know those type of gyros that you mentioned. Calibration shouldn't be an issue for them, but temperature·compensation might not be so easy. Those ADIS chips with SPI interface are·of good quality and they are affordable.
uM-FPU v3.1 is hundred times more accurate than the Floating Point Math Library of the Propeller in many functions. See, for example·
SIN(0.5)
FLOATLIB· 0.4794314······· 4 digit correct
UM-FPU··· 0.47942552····· ·7 digit correct
10 DIG··· ·0.4794255386
TAN(3.1)
FLOATLIB -0.041623········ ·3 digit correct
UM-FPU·· -0.041616516···· ·5 digit correct
10 DIG·· ·-0.04161665458
EXP(0.71)
FLOATLIB· 2.03398········· ·5 digit correct··········
UM-FPU··· 2.0339913······ ·7 digit correct····
10 DIG· ·· 2.033991258
Parallel driving of several uM-FPUs can be programmed using only 1 COG. Not yet on OBEX, but works like charm in the Propeller(I) Flight Simulator.
With the stored functions you get additional byte code space and·FPUs are much faster there than the Propeller Floating Point Library, and approx. 2-5 times faster than native PASM floating point code for some number crunching algorithms.··Such like complete WGS84 INS or solution of airplane flight dynamics equations with controls (1st FPU), or 3D graphics of the environment with correct clipping and hiding for dozens of ECEF 3D objects (not wireframe!)··from an arbitrary lat, lon alt position (2nd FPU) in real time (5-10Hz). TV Graphics is drawn by one Prop with the standard objects for that, the second Prop manages the system, including the FPUs.
··
istvan