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.
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.