Re: updated 9dof ahrs code
Málik Dávid
First: I created this mailing list for more easier communication with
everyone if some updates, news or issues come up.
Second: I'm writing because i found a few new problems, also reported
by others too.
The first problem is somewhat random and existed in the original code
too! In the "I2C.pde" file, on line 96 the code
"Wire.beginTransmission(CompassAddress);" was INCORRECTLY commented
out which caused read errors in the compass data. So to correct/fix
this problem, please uncomment this line.
The second problem is much more deeper than i first thought. Me and
others found, that if the HW is held vertically while/before
initialization, you get completely wrong euler-angle
values/orientation information. But this problem also existed in the
original code too, so if you download the original code from the
website and upload it to the HW, and initialize it while holding it
vertically, you will experience the "same" bogus behavement.
Now, i don't know why this is, but i suspect that the AHRS code uses
the start up values as the reference values... (?) If somebody have a
good idea why this is or how it could be fixed, please contact me or
write to this mailing list! Thx!
Third: I'm working on a totally new AHRS code which (hopefully) will
address these and other kind of problems/errors/issues and make a much
better AHRS code. So please look forward for the new code! :)
Regards,
David
Leszek
The second problem is because on this code we subtract 1G value from z
axis, so if we turn on HW vertically we subtract it from x or y axis and
have full value on z axis.
Third problem is when we turn on HW not in horizontal position eg. roll
and pitch is not 0, we have wrong magnetic heading, because function
Compass Heading use wrong Euler angels. Physically the magnetic axis x,
y, z is not on posistion roll=0, pitch=0 but in function Compass this
angles are use with value =0. To get good value I don't use en_ofsset
variable. Now my IMU always show me Euler angles = 0 only in horizontal
position.
Regards
Leszek
Andy Jalics
Just using the IMU_Razor9D0F.py AKA "Test for Razor 9DOF IMU by Jose
Julio" python visualization the uncommenting of the
"Wire.beginTransmission(CompassAddress);" seems to help.
Changing the Razor 9DOF code to 115200 baud seems to speed up the 3D
visualization for me.
Questions for Anyone:
1) Are you basing this changes on the SF9DOG_AHRS_1_0 code?
2) How is this code base even working for me now at all that the Razor
has gone from 2 Gyro chips(One one axis, and one 2 axis) to one (one 3
axis?
3) Pitch in the python visualization never seems to allow me to get
above about 85 degress when pointed up, it seems to wrap around in a
bad way.
David or others - if you are considering or are rewritting the code -
consider making it flexible where someone could add hooks later for
input from a GPS. (Personally in the end I'm interested in Dead
Reckoning for a autonomous ground vehicle...)
-Andy
Eric Jordan
Thank you very much for including me in this mailing list. I am completely new to this but will be working with several engineers and we hope that we can contribute.
Best Regards,
Eric
Málik Dávid
Thanks to Leszek's suggestion (that AN_OFFSET causing the 2. problem)
i took out AN_OFFSET from the algorithm and it fixed the problem
almost completely.
So I'm sending another updated code attached.
Q1) Are you basing this changes on the SF9DOG_AHRS_1_0 code?
A1) No, it is based on v1.1.
Q2) How is this code base even working for me now at all that the Razor
has gone from 2 Gyro chips(One one axis, and one 2 axis) to one (one 3
axis?
A2) Because other than the 2 gyros went from analog to 1 digital
3-axis gyro, almost nothing have changed relevant from the code's
perspective.
Q3) Pitch in the python visualization never seems to allow me to get
above about 85 degress when pointed up, it seems to wrap around in a
bad way.
A3) It is possible, I reach 89.xx degrees but you have to move slowly.
I think it is mostly because of quantization error, so this works just
OK.
About the previously mentioned yaw error, as Leszek suggested it is
caused by magnetic noise from other parts of the IMU board. This can
be compensated with a proper correction algorithm which I'm working
on. I think Leszek is also working on the problem, hope he sends
news/information if found any working solution.
If anyone else have found other/new problems/issues and/or have also
fix for it, do not hesitate to contact me/send it to me.
Regards,
David
On Sat, Jul 9, 2011 at 11:28 PM, Leszek <Lep...@wp.pl> wrote:
> W dniu 2011-07-09 23:08, Málik Dávid pisze:
Andrew Goldberg
Andy Jalics
I didn't get it working on a Mac, but I did get it working on a Linux
box.
It looks like it was originally written for Windows.
You can skip installing pywin - because it doesn't make sense for
Linux
or OSX(Mac) or other OSs.
Also, whatever OSX(Mac) USB serial device appears, replace COM9 on
Line
20 in the python script with that - for me in linux it was
port='/dev/ttyUSB3'. -- SAME goes for other windows users - replace
COM9
on Line 20 with the serial port that appears for your Razor 9DOF....
-Andy
On Jul 10, 7:01 pm, Andrew Goldberg <andrew.cue...@gmail.com> wrote:
> Hey, first off thanks to David for all your work on this, this is fantastic.
>
> A question, has anybody gotten the python program working on a mac?
>
Málik Dávid
You sent the email only to me, so i'm sending a copy of the message
and the answer to the list for the record.
1) The ADC.pde file contains mostly unused code, except for the
"read_adc()" function which is used by the Matrix_update() function.
Ofcource the code needs some clean up, but it hasn't been done yet. :)
2) Yes, we are aware of the yaw error, but its a hardware problem, not
a software problem... :( I tested it with the AHRS code and also with
the official sparkfun code. I suspect that the yaw error is caused by
EM noise from inside the board. It can be corrected through software
hard iron error compensation algorithms, but it need live calibration,
or by shielding the noise somehow which i haven't tested yet, but on
it. :)
3) The board when turned on, needs to be flat on the ground so it can
initialize itself and measure the gravity force and account for it,
but after it is turned on, you can move it around and it wont mess up
the heading. It will be able to "distinguish" between gravitational
acceleration and movement acceleration.
Now the code is far from perfect and more development is needed.
Regards,
David
2011/11/8 Rouhollah Alizadeh <rouhollah...@gmail.com>:
> hello all,
>
> thanx to everyone - its so nice of you working on this project as a
> group.
>
> I Had a few questions about the updated code :
>
> 1: What is the codes , in the ADC TAB for? Aren't all the sensors
> digital devices with I2C interface??!!
>
> 2: now that I upload the code on my board , I have a great deal of
> error on the yaw rotation , while the pitch angular is more than 30
> degree. any advice is appreciated .
>
> 3: According to the mathematical base of the DCM theory , mentioned in
> the Premelani and Bizard paper , shouldnt we be worry about the Accel
> signal , while the board is accelerating ?
Rouhollah Alizadeh
I'm working to clean up the code and maybe a filter to correct the
yaw .
by the way , would somebody tell me whats these code for? :
Vector_Cross_Product(&errorRollPitch[0],&Accel_Vector[0],&DCM_Matrix[2]
[0]);
Why it is just "Accel_Vector[0]" and not the "Accel_Vector" ? and also
for the DCM_Matrix.
Shouldnt the input of "Vector_Cross_Product" function be a "Vector
and matrix"?
and also plz :
Why it is "Vector_Scale(&Scaled_Omega_I[0],&errorYaw[0],Ki_YAW)" and
not "Scaled_Omega_I"???
So whats the need of "errorYaw[1]" or "errorYaw[2]"?
Thanx to all;
Málik Dávid
> Vector_Cross_Product(&errorRollPitch[0],&Accel_Vector[0],&DCM_Matrix[2]
> [0]);
>
> Why it is just "Accel_Vector[0]" and not the "Accel_Vector" ? and also
> for the DCM_Matrix.
>
The "Vector_Cross_Product()" function takes pointers as parameters:
"void Vector_Cross_Product(float vectorOut[3], float v1[3],float v2[3]) {...}"
By saysing "&errorRollPitch[0]" you take the first element ([0]) and
pass its address (&) to the function, so you pass the whole vector,
nut just its first element, so the function works perfectly.
Well, the "errorRollPitch" vector is a 3 element vector, so if you
would write "errorRollPitch" instead of "&errorRollPitch[0]" would
work fine. BUT! The "DCM_Matrix" is a 3x3 matrix, and you only want to
pass ONE of its vectors (columns) to the "Vector_Cross_Product()"
function, you HAVE TO say "&DCM_Matrix[2][0]", or "DCM_Matrix[2]".
So "&DCM_Matrix[2][0]" is equivalent with "DCM_Matrix[2]", and
"&errorRollPitch[0]" is equivalent with "errorRollPitch", so both are
good.
> Shouldnt the input of "Vector_Cross_Product" function be a "Vector
> and matrix"?
>
No, vector cross product is cross product of vectors, so you should
pass 2 vectors and an output vector where to write the result vector.
:)
> Why it is "Vector_Scale(&Scaled_Omega_I[0],&errorYaw[0],Ki_YAW)" and
> not "Scaled_Omega_I"???
> So whats the need of "errorYaw[1]" or "errorYaw[2]"?
>
"&Scaled_Omega_I[0]" is equivalent with "Scaled_Omega_I", and
"&errorYaw[0]" is equivalent with "errorYaw".
They are equivalent because the expression "&Scaled_Omega_I[0]" takes
the 1. element of the "Scaled_Omega_I" array, and they takes its
(memory) address. This is the same as expression "Scaled_Omega_I",
because always the address of the first element is stored in the
pointer "Scaled_Omega_I".
The whole "errorYaw" vector is used.
Regards,
David
Pete
I saw your post about cleaning up the code.. I took some time and did
all this already, so no real need of doing it again. I also made
it compatible with the SEN-10736 and SEN-10125 and added
sensor calibration and other stuff.
Here's the tutorial: https://dev.qu.tu-berlin.de/projects/sf-razor-9dof-ahrs/wiki/Tutorial
And right next to it is the code: https://dev.qu.tu-berlin.de/projects/sf-razor-9dof-ahrs/files
I'm quite sure the mentioned
> 3) Pitch in the python visualization never seems to allow me to get > above about 85 degress when pointed up, it seems to wrap around in a > bad way.
is because of missing calibration.The mentioned yaw error could be a
calibration thing as well. Could someone try it?
> A question, has anybody gotten the python program working on a mac?
Yes, but I had a hard time getting making it work, so I wrote a
test sketch using Processing, which is very easy to use on every
platform. It's included with the code.
Cheers,
Pete
PS: sorry for repeated posting.. fighting with the google groups
formatting.. ;)
Málik Dávid
On Tue, Nov 29, 2011 at 10:06 AM, Pete <peter...@gmx.de> wrote:
> Hi,
>
> I saw your post about cleaning up the code.. I took some time and did
> all this already, so no real need of doing it again. I also made it
> compatible with the SEN-10736 and SEN-10125 and added sensor
> calibration and other stuff.
> Here's the tutorial: https://dev.qu.tu-berlin.de/projects/sf-razor-9dof-ahrs/wiki/TutorialAnd
> right next to it is the code: https://dev.qu.tu-berlin.de/projects/sf-razor-9dof-ahrs/files
Looking forward to check it out! :)
> I'm quite sure the mentioned
>> 3) Pitch in the python visualization never seems to allow me to get
>> above about 85 degress when pointed up, it seems to wrap around in a
>> bad way.
> is because of missing calibration.
> The mentioned yaw error could be a calibration thing as well. Could
> someone try it?
No, i'm 99% sure the yaw error caused by magnetic noise from inside
the board. I tryed analysing the raw magnetic sensor data and it shows
a quasi fix board based magnetic offset vector. I am planning to make
an automatic calibration algorithm. But if you have better idea, I'm
open to suggestions. :)
>> A question, has anybody gotten the python program working on a mac?
> Yes, but I had a hard time getting making it work, so I wrote a test
> sketch using Processing, which is very easy to use on every platform.
> It's included with the code.
Its great news! :)
>
> Cheers,
> Pete
Regards,
David
Peter Bartz
>> I'm quite sure the mentioned
>>> 3) Pitch in the python visualization never seems to allow me to get
>>> above about 85 degress when pointed up, it seems to wrap around in a
>>> bad way.
>> is because of missing calibration.
>> The mentioned yaw error could be a calibration thing as well. Could
>> someone try it?
>
> No, i'm 99% sure the yaw error caused by magnetic noise from inside
> the board. I tryed analysing the raw magnetic sensor data and it shows
> a quasi fix board based magnetic offset vector. I am planning to make
> an automatic calibration algorithm. But if you have better idea, I'm
> open to suggestions. :)
Yes, that could be. I was seeing that offset as "uncalibrated sensor", because the accelerometer and the gyroscope have these constant offsets too. But it could well be that it has something to to with the way the parts are layed out on the board. The good thing is that the vectors really seem to be constant.
I also noticed that accelerometer and magnetometer give different values on each axis when applying the same force or field. That's why I added that calibration stuff based on the min/max readings for every axis.
Would be nice see the calibration values for different boards, it would be easy to see if the offset vectors point more or less in the same direction, which could clear up who to blame. I'll post mine here, maybe someone else could do that too:
// "accel x,y,z (min/max) = -278.00/270.00 -254.00/284.00 -294.00/235.00"
#define ACCEL_X_MIN ((float) -278)
#define ACCEL_X_MAX ((float) 270)
#define ACCEL_Y_MIN ((float) -254)
#define ACCEL_Y_MAX ((float) 284)
#define ACCEL_Z_MIN ((float) -294)
#define ACCEL_Z_MAX ((float) 235)
// "magn x,y,z (min/max) = -511.00/581.00 -516.00/568.00 -489.00/486.00"
#define MAGN_X_MIN ((float) -511)
#define MAGN_X_MAX ((float) 581)
#define MAGN_Y_MIN ((float) -516)
#define MAGN_Y_MAX ((float) 568)
#define MAGN_Z_MIN ((float) -489)
#define MAGN_Z_MAX ((float) 486)
//"gyro x,y,z (current/average) = -32.00/-34.82 102.00/100.41 -16.00/-16.38"
#define GYRO_AVERAGE_OFFSET_X ((float) -34.82)
#define GYRO_AVERAGE_OFFSET_Y ((float) 100.41)
#define GYRO_AVERAGE_OFFSET_Z ((float) -16.38)
Automatic calibration would be cool! Also I wanted to look into self-test and temparature-measurement features of the sensors.
Cheers,
Pete
Málik Dávid
I will post my min-max value later, but if you are interrested in an
automatic compensation algorithm, search/look for "hard iron error
compensation" and for "soft iron error compensation". There are some
calibration algorithms. I only implemented one of them, and while it
did helped/compensated some of the errors, it degraded by the time, so
it wasn't the optimal/best algorithm.