Replies to This Discussion

ModeratorPermalink Reply by Dr Mike Black on August 12, 2010 at 3:37pm

HI all,

Had a similar thing today, after a bit of deduction it turned out that, throttle reverse was wrong...using the same ol' chinese esc`s i suspect as everyone else they are reversed, but in the new code they are not...alll worked as predicted after NOT reversing it...

Also....GPS question...

using the trusty ublox...set the system up, got everything going the righ directions etc..prepped to legacy GCS...all working great....

then i noticed that my home ground alt was 350m.....i know that our building sits at 35m...so was expecting this...

conclusion dec point in wrong place...tracked down code and sorted the outputs to : instead of alt/100 to alt/1000 all reading on GCS at correct (ish) alt....went through all the proc calls for the GPS but cannot find the root of where this is calculated...

i think i have sorted the code to resolve the symptom not the cause...

when looking at alt hold its set in uploader to 120 for WP`s...but showed 40 in GCS..

can you point me to the root of the GPS calculations, as i think im only dealing with the symptoms..in debug...it was showing 350m also...so figured the gps was being screwey so replaced with a known one...same results..so concluded that its the code in this area..

lol...either it will head off in the stratosphere...of bury itself...not sure what the true GPS alt is.

OR - im missing summet real obvious to explain this phenomina..

a little explanation please if you get time..

Hoping to fly tomorrow, now everythings is working..just need to know how to read the exact GPS alt before i commit to aviation..

Many thanks.

Mike.

• ▶ Reply

Permalink Reply by Andre S on August 15, 2010 at 8:43am

Hi guys,

I had my APM maiden flight today with an Easy Star. I suppose it was more or less a success although the first flight ended in a dive. The EZ looks now looks like a boxer who received a full frontal punch which sent him to the ground. (see picture :-) But nothing actually broke and I think I'll be able to fix the nose with some boiling water.

Before the two flights I checked that FBW (FBW-A I believe) worked as expected. The rudder turned into the right direction when I left the sticks in the center position and rolled the plane. What I also noticed was that the elevator immediately after the rotation reacted but then went into neutral. What I did not notice was that depending on the direction of the roll it would either go up or down (which doesn't make sense to me.. it should either go up or down). Also it seems that the elevator movement was way to strong. Basically what happened in FBW mode during the flight was that when I moved the stick in one (left or right) direction it would either climb to a stall almost instantly or go into a dive.

Although I almost didn't dare to try RTL mode I'm glad I did since that stabilized the plane a lot better than FBW for some reason. I was able to turn it into either direction by giving rudder input and it seemed to start a loiter after the input stopped (although it did not really come back to my location). So that kind of surprised me a bit.

I know there have been some updates in SVN but is this here still the latest stable version? Couple of days ago I loaded the SVN trunk but that gave me other problems so I tried to fly this one,

Thanks for the great work. I'm wondering whether anybody could point me into the right direction if I'm maybe doing something wrong. I mean.. since the EZ does not have ailerons, do I need to take special care when setting certain parameters? I haven't changed gains or anything and believe to have followed the manual for connecting RC input/outputs.

Ah yes.. something else: tried to read out the onboard log but this is what I get:

Init ArduPilotMega 1.0.1 Alpha

Entering Log Read Mode...

ATT:-19,-54,-1

Error Reading END_BYTE

ATT:-56,-193,-2

Error Reading END_BYTE

ATT:-87,-307,-2

Error Reading END_BYTE

ATT:-110,-447,-1

Error Reading END_BYTE

ATT:-147,-537,1


and so on.. Do the errors mean something?

Andre

• ▶ Reply

Permalink Reply by Brett Glossop on August 15, 2010 at 3:49pm

Hi Andre and co,

I too have crashed an Easy by going into a control mode, mine this time was Stabilize (R605). (On a earlier revision of code it was RTL that the throttle was turned off, and yet Stabilize did what it was supposed too.) I've also seen, wait for it, the radio test do only half its business - surfaces controlled but values coming out stay steady - weird! Lots of weirdness in software behaviour usually means we aren't looking for the right thing. I'm thinking we need to erase the previous code before loading the new. The two times I've done this I have got good results (though on the ground). What do you guys think? Rubbish or might be something to it?

I'm getting the End byte error too and posted the problem somewhere else on diydrones.

Andre, be aware of another post I have made (the main APM page 26) It is about trims. Probably not a cause in your case but something we all should be wary of due to its potential to down planes.

Good luck Andre

• ▶ Reply

Permalink Reply by Brett Glossop on August 15, 2010 at 7:10pm

Another possible cause of crashes: interference.

Possible?
Think for a moment about the symptoms:
Works well on ground, even in control modes. but crash, or very odd and extreme plane behaviour in air.
Also sometimes the plane works fine in air.

My thinkings:
High revs or wires or ESC a little too close to APM and ker-plink and then crunch - the software jams and your cherished plane is heading straight to terra firma.
Different flights with same gear and yet different results - how can that be explained? The wires or ESC got moved a little closer to APM or you flying at higher revs.
Happens on some planes not others? Explaination: above line plus different motors with different amounts of interference/induction due to different gear.

What do you think?
(I will try out some shielding and reorganising and test when I can.)

• ▶ Reply

Permalink Reply by Greg Fletcher on August 15, 2010 at 7:40pm

Tag your changes in your comments. That way those of us that have made additions/changes can keep up with your changes. I tag stuff with my initials(// ***GAF***) You could do the same only add a version # and others could implement your changes to their custom/experimental code. Like this (// ***DW*v1.013***). Then one could search the new code for the latest changes and copy them into a custom version. I have additions I want to add, but am constantly waiting for the code to finalize before making my changes. I end up waiting forever or I make my changes and then have to do it all over again for a new version because I'm not sure exactly what has changed. Just thought this would spur more open source innovation. What do you think?

• ▶ Reply

Permalink Reply by Brett Glossop on August 16, 2010 at 1:12am

Good point about the commenting tag for your custom work. I agree.
With larger pieces of custom coding one could have a separate .h file with an include statement in an appropriate place of the standard code.

• ▶ Reply

Permalink Reply by Uwe Gartmann on August 16, 2010 at 1:45pm

IMHO tagging is nice for nearly final code. Software in alpha status get just too many changes to be tagged. Once the APM software is beta, I will port the code to eclipse. Hopefully, just bug fixing and minor changes are made from this point on.

• ▶ Reply

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