Jason and I have just completed a major update to the ArduPilot Mega code.  We have updated the version to 1.0.1 to reflect the change.  It is in the repository and ready for alpha testers.  Look for revision R418 or later.

The change you will most need to know about before proceeding is that we have enabled the dip switches for mixing mode (normal vs elevon/V-tail), and roll, pitch and rudder reversing.  The four switches from left to right are roll, pitch, rudder, and mixing.  These reversing parameters have been removed from the config file - you must use the dip switches.

Additional features that have been added include
  • Magnetometer support
  • Airspeed sensor support
  • Telemetry in binary format for the upcoming GCS release
  • Additional functionality for the X-plane simulator
  • New commands and modes added
  • Relay support
  • Battery voltage measurement supported
and more stuff I am forgetting at the moment.  Documentation for all the changes is very limited at this point, but we will be working on it.

In addition to new features the code underwent a lot of structural change and cleanup.  This is an alpha release so expect a few bugs.

Please let us know your testing results.  We would like to move this version towards a beta release.

Tags: ArduPilot, Mega

Views: 142

Reply to This

Replies to This Discussion

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.
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
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
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.)
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?
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.
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.

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Drone Delivery Challenge, is here

© 2014   Created by Chris Anderson.

Badges  |  Report an Issue  |  Terms of Service