ArduIMU horizontal initialization

When ArduIMU initializes it accepts the horizontal plane to be the plane of initialization.  For example, if I initialize ArduIMU tilted 45 deg in the roll axis it will begin outputting 0 deg roll when it initializes, and will count everything now from that 45 deg position.  I thought that it should be capable of determining its orientation in space based on the reading from accelerometer since we always have 1G acceleration present (gravity) in the vertical direction.  Am I doing something wrong or this is the way it is supposed to be?  Don't know if it matters or not, but I don't have a GPS connected for this test.

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • I have never used this particular IMU with any open source autopilot, but do you all guys really place your aircraft perfectly horizontally before you turn the autopilot on and wait for it to initialize?  And from there on it becomes your horizon?  Seems like an awkward way of doing things.

     

    Alright, since everybody here were so helpful, I'll post a solution of sorts ... for the posterity sake.  In the startup_ground subroutine of the IMU code, when IMU initializes it takes a bunch of consecutive reading of the accelerometer output and then "averages" them and assumes that it is the horizontal plane.  In my "non autopilot" application I needed the IMU to "find" the horizon by itself, because the orientation during its initialization was unknown.  The output of the ADXL335 accelerometer is biased right in the middle of the power supply for the 0 G condition.  In other word if you put your IMU perfectly horizontal and the input voltage is 3.3V the output for x and y will read a number corresponding to 1.65V output.  So knowing that you can just hard code the magic numbers for the horizontal plane.  There are several things which can affect the accuracy of this: the range of the 0G output given by the specsheet is 20% in x and y and 40% in z direction.  0_0  How about them apples?  I have only one unit here to experiment with, but mine comes up pretty close to the "dead center" every time.  So I would hypothesize that this range refers to the static value that doesn't change with time and related to the way the chip has been manufactured.  In that case it can be mitigated by initial adjustment of the "magic numbers"  Now, if it is temperature dependent,  then it is really not going to work.  The other unknown is the fluctuation of the 3.3 power supply on your IMU board.  Mine remains pretty close to 3.3

     

    What I did in the code is commented out the line: //AN_OFFSET[5]-=GRAVITY*SENSOR_SIGN[5]; and added the following:
            AN_OFFSET[3] = 500;
            AN_OFFSET[4] = 500;
            AN_OFFSET[5] = 520;

    Those numbers seem to work pretty good.

     

    A better way to do it would be to use it as a starting point and then assuming that the aircraft is not moving measure the gravity using those values. If it the value is higher or lower than 9.8 then adjust those starting numbers proportionally (that would be an assumption that they all drift proportionally)  However in my case it seems to be working just fine as is.

     

     

This reply was deleted.

Activity

DIY Robocars via Twitter
Videos from the ICRA autonomous racing workshop are now available: https://linklab-uva.github.io/icra-autonomous-racing/
Thursday
DIY Robocars via Twitter
RT @SmallpixelCar: Prepared race track for Warm Spring Raceways @wsraceways and looking forward to test my new car at RAMS RC @ramsaicar fa…
Jun 6
DIY Robocars via Twitter
RT @f1tenth: Trying out some nasty blocking maneuvers 🏎️🤖 #f1tenth #autonomousracing https://t.co/nMTstsaogM
Jun 5
DIY Robocars via Twitter
May 27
DIY Robocars via Twitter
RT @araffin2: I will talk this Saturday from 18:00 to 19:00 Paris time for the @diyrobocars community about learning to race in hours using…
May 27
DIY Robocars via Twitter
RT @a1k0n: Luckily the infeasible hairpin problem was easily reproducible in simulation and I could test the fix before bringing the car ba…
May 26
DIY Robocars via Twitter
RT @a1k0n: Another problem was that I was over-constraining the car's allowed accelerations, so it didn't think it could turn as tight as i…
May 26
DIY Robocars via Twitter
RT @a1k0n: Breaking the map up into two halves worked, but I had to be more careful about separating the inner track from outer. There's se…
May 26
DIY Robocars via Twitter
RT @a1k0n: Here's a datalog for my fastest lap of the day. Lap timer is tiny window lower-left. https://t.co/myrlWWrKUY
May 26
DIY Robocars via Twitter
May 26
DIY Robocars via Twitter
RT @a1k0n: Here was my car's POV. Man this track is confusing in first-person! After the incident my camera was all scuffed up and I was af…
May 23
DIY Robocars via Twitter
RT @circuitlaunch: Loved seeing so many familiar (masked) faces at Circuit Launch today for our first in person @diyrobocars in over a year…
May 22
DIY Robocars via Twitter
RT @circuitlaunch: Last but not least, mystery guest @BostonDynamics Spot took to the track @diyrobocars He enjoyed the #brazilianbbq too 😂…
May 22
DIY Robocars via Twitter
RT @SmallpixelCar: Today’s race @circuitlaunch for @diyrobocars with @a1k0n Was busy in the morning and did not get a chance to tune camera…
May 22
DIY Robocars via Twitter
RT @a1k0n: This was epic. My car was barely working this morning, had to make a lot of changes and extremely dirty hacks. Post-race analysi…
May 22
DIY Robocars via Twitter
DIY Robocars @ Circuit Launch, 3/7/2020 https://twitch.tv/diyrobocars
May 22
More…