Developer

APMega - 1.0.1 alpha now in the repository

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.

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • 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?
  • 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.)
  • 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
  • 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 Doug,
    Just tested R455 using pre-alpha library (which is the latest library I presume?)

    I discovered that the throttle went max after startup in manual mode.(always fun ;-)
    Double checked config values that made earlier version suit my setup but same result 2nd time.
    I could have missed a define or similar. Maybe a new one?

    I've attached log just in case it helps.

    APM_test_R455.txt

    https://storage.ning.com/topology/rest/1.0/file/get/3692074764?profile=original
  • Developer
    Hello testers,

    I have noticed that there is a bug in the ublox library – it reports ground course as degrees * 100000. The other gps libraries report it as degrees * 100.

    It seems I expected the scaling from the ublox library and Jason expected the scaling from the MTK, so various revisions will have ground course working or not depending on which gps you are using. At the present I would recommend R433 for the MediaTek gps and R434 for the Ublox.

    I have reported the bug to the arducopter guys maintaining the library. We will get it corrected and adjust the APM code.
    100.it
  • Developer
    Doug,

    Any chance that you could create a Tags directory and start tagging your drops?

    It'd really help folks that are trying to track your changes, especially with "and more stuff I am forgetting at the moment".

    # svn mkdir http://ardupilot-mega.googlecode.com/svn/Tags
    # svn copy http://ardupilot-mega.googlecode.com/svn/Trunk http://ardupilot-mega.googlecode.com/svn/Tags/APM1.0.1.a1

    Thanks for all the hard work!

    = Mike
This reply was deleted.

Activity