Replies to This Discussion

Permalink Reply by Harry on July 29, 2012 at 2:23am

The latest version of code I'm working with.

Attachments:

• AutoStab_IMUV32-120728a.zip, 27 KB

• ▶ Reply

Permalink Reply by Harry on July 29, 2012 at 4:12pm

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.

• ▶ Reply

Permalink Reply by Greg Fletcher on July 29, 2012 at 7:40pm

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.

• ▶ Reply

Permalink Reply by Jeff Smith on July 29, 2012 at 9:19pm

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 :-)

• ▶ Reply

Permalink Reply by Jeff Smith on July 29, 2012 at 9:31pm

Here's the 250 flybarred

And here is a close up of the space I'm working in (28mm wide, 40mm long, and 20mm tall).

• ▶ Reply

Permalink Reply by Harry on July 30, 2012 at 12:34am

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.

 

  

• ▶ Reply

Permalink Reply by Jeff Smith on July 30, 2012 at 5:37pm

Wow, I went and looked into matrixes, got sucked into a good tutorial on IMU's and now I'm back in trig relearning all the math :-)

I have no idea how you guys have understood all the theory to the point that you can write code to make it all function :-0

I am humbled.

• ▶ Reply

Permalink Reply by Jeff Smith on July 30, 2012 at 11:08pm

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

• ▶ Reply

Permalink Reply by Harry on July 31, 2012 at 12:51am

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.

• ▶ Reply

Permalink Reply by Jeff Smith on July 31, 2012 at 6:13am

Well, I think I am starting to see the forest for the trees :-)

After reading a bunch and getting a better text viewer Lol

I believe the B1000000 numbers in the PPM code is the actual binary bits being received on that pin. If I understand Greg is setting high and low limits for the if and else statements?

• ▶ Reply

Permalink Reply by Jeff Smith on July 31, 2012 at 6:32am

I also see now that there are only pitch, roll, and yaw in Greg's code, I'll have to look again at the APM code to see how it is different. Man I wish my AdruIMU was already here.

I think I'll order a second one today from sparkfun since I still need a programmer anyway.

Permalink Reply by Jeff Smith on August 1, 2012 at 9:28pm

Edit: wrong place to reply

• ‹ Previous
• 1
• 2
• 3
• 4
• 5
• …
• 14
• Next ›
• Page