'm having some trouble adapting the new IMU v3 to Jean-Louis' code written for tricopters. His code used the APM_Compass library and for some reason, it wont compile with any reference to that library. The new IMU doesnt use that library, so I havent let that stop me from trying. It compiles and gives me output, but something is still wrong. The debug wont print GPS and the attitude values although stable seem way off. I'm hoping some experts can look at my code and tell me what's wrong or even what is right.
I've included the code I have now. Please help if you can.ardimupter-120708b.zip
The latest version of code I'm working with.
This holds the key: http://code.google.com/p/gimbal-controler/wiki/IMU_3_gimbal_controler That program was written by Greg Fletcher and he pointed out that MPU6000 on SPI interferes with the digital output on the V3 board. He was very nice to lead me to his program. It'll take a lot more work, but the reason only one motor would work has been explained. Space will be critical, but there's a chance now that this will work.
Thanks Harry, I think this will work just fine. Eliminating all the extra matrix arrays and other variables from the camera stabilization will save a lot of ram. Its doing the stabilization and control routines at 200 Hz. With out all that extra baggage it will maybe do 400 Hz, which would make a decent copter controller. I don't think there is enough program mem to do waypoint navigation. We can start with the basic essentials and add functions with space available. We can also use the DMP code now, which should help a lot, but I would go first with DCM because it all ready there and works.
Thanks in advance for helping out :-) An absolute noob like me can't get far without guys like yourself and Harry leading the way.
I am hoping that getting your ArduIMU gimbal code to play nice with a tri-copter will put it a few tweaks away from working as a micro flybarless module for a traditional heli, what do you think, is it possible?
I don't need any functions other than stabilization, of course an acro mode that could be in-flight switched back to stabilize would be fantastic, and a loiter mode would be the be-all-end-all...
My platform is an Align 250 Pro DFC (flybarless) which is replacing/pairing up with my 250 fly-barred that I'm just getting tired of rebuilding from the endless cycle of crashes... It is just so quick I keep flying it into a dirt nap the split second I loose orientation :-/ I have a 600efl that I've had for even longer and never crashed yet, but it tolerates wind and isn't so nimble. I'm dying for an auto-leveling solution that will fit inside the 28mm wide frame. I've got the tail gyro, 6ch receiver, and the Phoenix ICE HV-50 esc all packaged real nice inside the frame (I'll post up a few pic's). If I could replace the gyro with the ArduIMU as a copter controller, I would have a golden setup that would allow me a moment to let off the sticks and recover my bearings. And save me about $120 a crash.
I see you have code in place for PPM input and PPM output, is it reasonable to think that I could pull the raw PPM from the receiver, process it with the ArduIMU, then return it to the receivers PPM decoder to drive the servo's? (basically hack the ArduIMU right into the signal path inside the receiver) it would significantly reduce the wiring I'd have to put in place for this system.
I've got an align 3GX sitting her that will not auto-level, an APM 2.0 that is just too big, a spare APM 2.0 that I'm gonna rip the daughter board off of to mount under the 250 for now, an APM 2.5 on the way with all the external sensors one can buy for my 600, and an ArduIMU_V3 on it's way as well. So I'm not trying to cheap out on a solution, I just want to find something that fits the scale and intent of this little riot :-)
Greg, your code is pretty sophisticated and it will make a good copter. I'm not smart enough to add a 4th channel and that seems like step 1. I have no idea where those B1000000 numbers come from or TNTC1 something or other. That seems like chip architecture stuff and I would surely mess that up at this point.
I havent let ingnorance stop me yet, so I did an experiment with the code I was mangling before you pointed out the problem. I just reassigned the pins. Unsoldered my connectors and moved them. I hooked it up and it started, even with the MPU6000. When I move the IMU, all the motors react. I've got the motors and servo in the wrong slots, but they work. That's huge for me. I notice the gimbal program has fine tuned the IMU, so I'll see if I can make use of that. As is, attitude is drifting all over the place.
After looking into the amount of code it takes to process the raw sensor data I am really hoping we can implement the DMP on the 6000 and just deal with GPS and Compass integration on the IMU's processor...
Be cool to make some progress on this before my brain grinds to a halt LOL
I'm waiting on some props and when I get them I'll be able to test it out in the air. I just moved the output to A0...A3. If Greg hadnt let me know the pin conflicts with the MPU6000, I never would have known to try it. It works on the ground.
Greg's code is very good and he thinks it will be faster and that's critical to these multirotors, but I need a book on these Atmegas and Arduino where there is some handholding to explain things. The low level stuff is what makes em tick literally.
That's how I see it now, crack the low level and all the C makes better sense. When I get there, I'm going to take another look at adapting his gimbal code to a tricopter.
Edit: wrong place to reply