I'm still playing with DCM

I burned out my ArduIMU V3 and still want to play so I took my flip1.5 with the MPU6050 and created a Frankenstein version of the 3DR ArduIMU1.9 code.  I got rid of the fastserial headache and used FreeIMU to initialize and retrieve the sensors over i2c, using the arduino 1.0.3

First problem I had was the orientation of the sensors is different from the ArduIMU, so I had to make several trials before I had a clue how to fix it.  I changed the order of how the ADC tab reads in the sensors and finally got it right.  I got my sensor signs from FreeIMU.

Luckily, the MPU6000 and 6050 are really the same except for how it communicates.  That meant I didn't have to change the constants for gravity or gain. 

Once I had the basic IMU working, I wanted to add GPS so that it could use DCM to lock yaw. The problem here is the flip1.5 uses a separate board over i2c to process GPS.  To get lat and lon into the DCM, I needed to read the multiwiiserial protocol.  It took some work to figure it out but it wasn't too bad.  I'm still not sure on some of the units like is it in cm or m and which does DCM need. 

Anyway, it works.  With it stationary and a fix, if GPS gets wild and erroneously reports a fast enough ground speed, the Arduimu test program will show the plane turning to match the ground course.  This is how it should work, but in the air and moving the course and speed will be much truer to life.

The actual changes to the ArduIMU 1.9 program were minimal, with me only replacing the sensor initialization and how it reads GPS, and which pins correspond to the LEDs.

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

Join diydrones

Email me when people reply –

Replies

  • The jumpiness is the least of my problems.  I/ve been testing without GPS because I was using an i2cNav board and it stopped working.  My FTDI cable had a broken wire and I couldn't upload anything with it.  I had to strip the covering off the cable and then resolder, but somewhere along I lost the connector and had to use single position header thing connectors.  I got tired of not having GPS, so I fixed it.  Then I had to figure out what color coded wires were what as the new connectors had random colors - grey is black, orange is green, etc.  I reloaded the code and have GPS again.

    So now here is what I have done.  The board I'm using has the MPU6050 is oriented different from the ArduIMU and I swapped the order of the accel and gyro inputs, so I didn't have to change the DCM stuff which I barely understand.  That way, any changes needed to orient it are easier for me.  That takes care of the accel and gyro, but I need mag too.  I had a hell of time orienting that too and used the same strategy, modify the order and sign of the sensor readings and leave the rest alone. 

    The problem now is as soon as I read GPS, the heading is turned 90 degrees to West.  No position, or take out the GPS and North is North and not West, etc. 

    What in the DCM could possibly need swapping or sign change?   

  • I'm still playing around with this..  I have the DCM working like designed.  I have a few programs for viewing the orientation solution, including a crude android app but I'm not entirely happy with things.  I've run FreeIMU unaltered and it seems to be better in how it reacts to sharp quick movement, but then fails in controlling drift.  The DCM at neutral sits there and quivers slightly around 0 pitch and 0 roll.  The calibrated Mag stops drift much better than FreeIMU, but if I give it a quick jolt in Roll, it will show as some huge Roll in the opposite direction before it shows the proper angle.  I tested this in the car, too.  As the car accelerated forward, it showed a pitch down.  As the car turned right or left, the turn shows as a roll in the opposite direction.  The DCM shows proper attitude when I hold it in my hand and rotate it gently.  It's the way it reacts to sharp accelerations that has me puzzled.  I tested an APM running arducopter in the car too and it doesn't do this. 

    What am I seeing here?     

  • Like I posted above, I'm using the ArduIMU v3 program with a board that uses i2c instead of spi and it works.  I'm working on using it as a stabilizer.  I've got it reading my rx and tried Servo.h to write to a Servo using the roll angle and another Servo using stick input.  All I need is to write something that uses stick and IMU and PIDs.  Not that easy for me but its been done by others many times.

    • I noticed a problem.  I have it mounted level and it will run for hours and never show a problem.....until.  Until I put it into a fixed bank of say 45 degrees and let it sit that way for several minutes.  What happens is it starts to roll on its own.  It'll hold the fixed 45 degree bank for maybe 10 minutes and then start drifting.  If I put it back level, it recovers to level like it should.

      What is going on there?

      • I just tested it again.  This time I put it into a 15 degree bank and left it running for an hour and it held.  I then increased it to 45 degrees and it drifted in pitch and roll.  I put it back to level and it was fine.  The yaw is not a problem with GPS.

        • I increased the bank to 30 degrees and an hour later its still holding.  I'll find the limit, but why and what is the problem?  Is it something in DCM or the MPU or a problem with the offsets in EEPROM? 

          • I played with the DCM integration time and added the magnetometer and the drift at steep bank angles went away. 

            Adding the magnetometer was a pain.  Getting it to read the mag was easy, getting it right was not.  My mag is oriented 90 degrees from the ArduIMU so pitch and roll are screwed up in the DCM.  I used MagMaster to calibrate and saw which axis is X and which is Y and then reversed X and Y in the code and it finally is correct.

            • But not so fast there kid, the tilt compensation was only right in certain quadrants and I got fooled into thinking I nailed it.  I swapped the order of mag_x and mag_y and it was still messed up.  Finally, I got it when I changed the sign of roll in the HMC5883_calculate function and removed the - sign from the Heading = atan2(-Head_Y, Head_X).    Oh, I also had to change my declination from negative to positive. 

              Now, I have some room to try to stabilize some servos I hope.

This reply was deleted.

Activity

DIY Robocars via Twitter
Practice virtual race this Saturday; the real thing will be on Oct 3 https://www.meetup.com/DIYRobocars/
Wednesday
DIY Robocars via Twitter
Wednesday
Derrick Davies liked lisa TDrones's profile
Wednesday
DIY Robocars via Twitter
Monday
DIY Robocars via Twitter
RT @SahikaGenc: AWS DeepRacer & Hot Wheels Track https://youtu.be/4H0Ei07RdR4 via @YouTube
Sep 14
DIY Robocars via Twitter
Sep 8
DIY Robocars via Twitter
RT @davsca1: We are releasing the code of our Fisher Information Field, the first dedicated map for perception-aware planning that is >10x…
Sep 8
DIY Robocars via Twitter
RT @SmallpixelCar: How this works: 1)object detection to find cones in single camera image, 30 frames/sec on @NVIDIAEmbedded Xavier. 2)comp…
Sep 8
DIY Robocars via Twitter
RT @SmallpixelCar: Use two color cones to guide the robocar. No map needed, on onsite training needed. Just place the cones and it will fol…
Sep 7
DIY Robocars via Twitter
Sep 7
DIY Robocars via Twitter
RT @roboton_io: Great to see http://roboton.io running at 60fps on the cheapest #chromebook we could find! #edtech #robotics #educat…
Sep 3
DIY Robocars via Twitter
RT @openmvcam: Crazy in-depth article about using the OpenMV Cam for Astrophotography: https://github.com/frank26080115/OpemMV-Astrophotography-Gear https://t.co/BPoK9QDEwS
Sep 3
DIY Robocars via Twitter
RT @openmvcam: Hi folks, it's finally here! Our first draft of our Arduino Interface Library is out! It works over SoftwareSerial, Hardware…
Sep 3
DIY Robocars via Twitter
RT @chr1sa: Please let them have an open API. This would be perfect for @DIYRobocars races https://twitter.com/NintendoAmerica/status/1301513099707658246
Sep 3
DIY Robocars via Twitter
RT @SmallpixelCar: Lanenet pretty much used all my GPU power on @NVIDIAEmbedded Xavier since I optimized with tensorRT. I need to run anoth…
Sep 3
DIY Robocars via Twitter
RT @LyftLevel5: Our @kaggle competition on Motion Prediction for Autonomous Vehicles is now live! Experiment with the largest-ever self-dri…
Aug 24
More…