I’m working on a quadcopter using the navio board. I’ve created a ±4 millionths of a second PWM->ppm program. and a lot of tests. My experience is making an arduino 256 max board with a 9250 mpu using the DMP (without gps or barometer or magnetometer available- I was working with the 6050) link (link is within the ground effect. and running at 50hz)
Here’s a link to my PWM2PPM 8 channel conversion arduino program. PWM2PPMFast up to 8 channels, and should be fairly accurate. (±4us on a nano, but depends on the arduino)
here’s my 8 month blog since the navio was created as an idea. Thank you Navio people without its creation and idea, I wouldnt have even looked into this. Old quad I now have a blog for my progress, for people that can understand… Badly formatted blog
Mathew, do you have some pictures of your setup with Navio?
I’ve added a plastic box to contain the electronics today and I still need to make holes for all the PWM leads (hence the lids not on and not all ESC’s connected). Its powered up in this pic, and I’ve also got a VA meter on the one propeller.
On the right hand side of the plastic box you can see the arduino nano and the radio receiver (could do with shoter jumper cables tho).
Well I side tracked (was just attempting the conversion, wasnt expecting it to actually work! at least not so easily). Managed to get the DMP on the 9250 to work on the Raspberry PI here’s the code DMP Code. Its a conversion of the 6050 library for the Arduino by Jeff Rowberg.
Benefits of using the DMP are basically less CPU usage and SPI bandwidth, its more accurate than using the raw Accelerometer/Gyro values at a lower frequency than 1khz. The DMP on the Invensense MPU’s is designed to take load off the main CPU. By itself (and without console print out) at 50hz it uses 1.4-1.6% CPU usage Vs the Navio example AHRS program at 1khz pretty much at 100% CPU usage.
Mathew, AHRS example will use all the CPU time it can get as it is not optimized, so it’s not the best comparison target. APM uses 9-12% CPU for all of it’s logic including sampling MPU9250 with 1000Hz rate.
1 Like
It flies! 
Quad vid
Still need to use GPS/Barometer (I’m reading them both just not using them at the moment) and tune out the wobble but it works
Mathew, congratulations! Doing all that with your own code is great:)
Amazing job Matthew.
Mathew, great job!!
Could you upload your SPIdev library?
Thank you!
I’m using the same one as the Navio examples on the B+. (modified for the PI 2-B as per the other thread)
Thank you Mathew,
One more question. Can I change the initial z axis value of MPU to change the angle of inclination of x and y axis?
Yep, you’ll need to put values into the offset functions (the gyro offset is for drift compensation):
setXAccelOffset(5590);
setYAccelOffset(5140);
setZAccelOffset(11362);
setXGyroOffset(-69);
setYGyroOffset(-47);
setZGyroOffset(10);
You can get the numbers to put in by placing the board in the orientation you want to be flat and running MPU-Calibrate It will take a couple of minutes to run and at the end list the values to put in.
New video with the 280 watt motors & Raspberry PI 2
Video
Needed to make lots of changes to the PID when I went to the new motors which is why its taken so long. Its also not wobbling anywhere near as much as the previous video Controls are a little weak (the largest angle it rotated was probably around 20 degrees) but they are responsive. I think it was pulling slightly to the left in the video too so might need a small adjustment there.
As you can see at 20 seconds in it does a little jump, that was unintentional and likely something to do with how I’m using the accelerometer for height stabilisation but I’m still working on that.
Yep, still using the DMP. I might make a second version that doesnt, the DMP sort of gets in the way sometimes.
I know its been a while, but the maths is actually pretty tricky. I’ve now found a fatal flaw in the DMP code, It seems it’s got a constant callibration calculation in the “black box” of the DMP code. this causes it to not have a fixed horizon.which isnt good for a quadcopter so I’ve now made a new program that uses the raw data at 1khz. currently I’m averaging 20 samples of the accelerometer and gyros and then updating the gravity using a complementary filter and integrating the gyro z value for a yaw value from the perspective of the quad.
I’m trying to simplify the equations required for a quadcopter so they are understandable for someone with rudementary trigonometry
Could someone with knowledge tell me why my algorithm for correcting pitch and roll via the magnetometer doesnt work as a feedback loop in the testahrs algorithm. It seemed a pretty obvious thing to try, now my magnetometer adjustment isnt quite correct (it might be pointing east or west instead of north/south) but the algorithm doesnt have a problem with that.
enter link description here
Actually never mind, it does seem to work as expected. Just need to get the axis’ correct (and work out a faster way to get the magnetic inclination). It assumes 2 things, the magnetic field (ignoring noise) doesnt change over time and 2 the gravity calculated from the accelerometer/gyro’s is on average correct.