Developer Comment by Ryan Beall on February 12, 2010 at 11:19am

Awesome, can't wait to load it up. I have a threeday weekend with nothing to do!

Developer Comment by Mark Colwell on February 12, 2010 at 1:19pm

Both new code versions uploaded to Stryker II. Now adjusting servo trims so stabilize trim = manual trim, Looks like this version may fly, mixing is good, I will tune roll & pitch PIDs with manual throttle control. Then full auto.

Developer Comment by Doug Weibel on February 12, 2010 at 1:43pm

I wish I had time to actually test my drones. Work, work, work + family. As my father would say - "no rest for the wicked" ;)

Comment by Dave Mincin on February 12, 2010 at 3:26pm

Hey Doug, I'm using a slightly modified version of this code on different hardware, but it's been working quite well. Thanks!!

I based my code on an earlier version (v14 I believe) and am just now looking into merging in some of the latest updates. One thing I've noticed is that the order of the parameters being passed to the Vector_Cross_Product call in roll_pitch_drift have been swapped.

I have:

Vector_Cross_Product(&errorRollPitch[0],&DCM_Matrix[2][0],&Accel_Vector[0]); //adjust the ground of reference

but it appears at some point later it has been changed to:

Vector_Cross_Product(&errorRollPitch[0],&Accel_Vector[0],&DCM_Matrix[2][0]); //adjust the ground of reference

Now my roll angle (haven't checked the others yet) at startup quickly increments up to 179.xx degrees instead of converging on zero. It also appears that instead of going past 180.0 degrees it becomes negative on the other side of 180.0.

Was there another change that accompanied changing the cross product direction? I'm thinking perhaps my sensor signs need to be adjusted to reverse the direction of the cross product result?

Any thoughts?

Thanks,
Dave

Developer Comment by Doug Weibel on February 12, 2010 at 4:15pm

Hey Dave,

You didn't see much activity in the repository but Jose, Andrew and I worked for quite a while to find the bug in the gps parser and for a long time we thought it was a problem in the DMC algorithm code, so lots of changes were made. I don't remember that one in particular or what the corresponding change would be.

All of the angles should have a range of -180 to 180. I think we had an error in an earlier revision that had a range of 0-360 on one or more, but you really want -180 to 180 for the range.

Developer Comment by jasonshort on February 12, 2010 at 7:19pm

Hey Doug,
I had to rework that GPS parser a lot for 2.5. Check it out.

Checksumming has an issue:
if((ck_a=UBX_ck_a)&&(ck_b=UBX_ck_a)) // Verify the received checksum with the generated checksum..

Should be:
if((ck_a == UBX_ck_a) && (ck_b == UBX_ck_b)){ // Verify the received checksum with the generated checksum..

I also had to check if I had a god fix before parsing the data. The uBox was outputting the last known good location over and over. That was messing me up and causing issue with the GPS light functionality.

Comment by Rana on February 12, 2010 at 8:04pm

Excellent Doug !
I just placed order for one ArduIMU Flat and Ardustation.
Has someone flight tested 1.5 ?

Developer Comment by Doug Weibel on February 12, 2010 at 9:06pm

The weather and my schedule have been conspiring against me. Mark Colwell and Ryan Beall may flight test it this weekend. I will do so next week.

Moderator Comment by Thomas J Coyle III on February 12, 2010 at 9:20pm

Jason,

The error in the checksum calculations was found and discussed around the middle of last year. I am suprised that you did not know about it and that it was not corrected and was continued to be carried forward in the later versions.

Regards,
TCIII

3D Robotics Comment by Jordi Muñoz on February 12, 2010 at 9:26pm

Hello Jason,

Thomas is correct, i was notified about that issue and i corrected it. But i don't what happen, maybe is some kind of regenerative bug LOL. I guess it get lost in the repertory and could be erased with a newer version of the uBlox parser.

Comment

• ‹ Previous
• 1
• 2
• Next ›
• Page