Version 2.6 of the ArduCopter code is now available in the AP Mission Planner and in the downloads area!

 

Updates to MavLink 1.0 means you will need to use "ArdupilotMegaPlanner10.exe" to connect.  If you've updated your mission planner recently you should find this executable in the directory where the mission planner is installed.

 

The above video is done using a prototype 3dr ublox GPS which seems to have better accuracy than the standard mediatek.

 

Improvements over 2.5.5 include:
     - MavLink 1.0 support (use with ArdupilotMegaPlanner10.exe) [Tridge, Craig]

     - Stability improvements especially during level hover [Jason]

     - throttle range improvement (higher min and max) [Jason]

     - improved standard Loiter PIDs [Alan, Heino, Jason, Angel]

     - dataflash erase speed up ('+' messages removed but it only takes 6 seconds now) [Tridge]

     - Copter LEDs [Robert Lefebvre]

     - RTL loiter stage target set to home to improve final landing position [Jason]

     - flip & acro improvements [Jason]

     - circle mode target improvement for ground station [Jason]

     - Auto Approach [Adam Rivera / Marco]

 

Bug fixes include:

     - UBLOX driver fixes (lock should now be more reliable) [Tridge]

     - enable mavlink messages during dataflash erase which resolves issue in which new APMs fresh from the factory appeared unresponsive [Tridge]

     - proper printing of lat/lon values in dataflash logs [Randy]

     - removed duplicate GPS reads [Jason]

     - resolve flooding of telemetry link with low-battery warnings [Tridge]

     - RTL bug would land if rtl_approach_alt was more than 1 [Jason]

     - WP Radius could not be set larger than 1.3m [Jason/Randy]

 

Tuning:
PIDs are optimised for the 3DR/Jdrones quad with 850 motors and 10" props.  If you're using more powerful motors/props and are seeing bad flight behaviour in stabilize, start by turning down Rate Roll P in 25% steps.

This time we spent some time optimising the loiter PIDs.  Tuning loiter can be tricky so please refer to the discussions which will appear below for more community feedback on what parameters work best.
 
All feedback welcome below.  Enhancement requests and bug reports can be put into the arducopter issues list.  When possible please include logs (tlog and/or dataflash) and tell us whether you're using APM1 or APM2 and what version of the software you're using (presumably 2.6 but tell us anyway!).

 

Happy flying!

Views: 64327

Reply to This

Replies to This Discussion

Yes, I think Robert's checking in the changes to trunk.  So it'll likely show up in 2.6.1 which isn't that far off actually.

Palo,

     Those are in degrees * 100.    So it's not terribly unusual for it to have big jumps like.  Now, if it wasn't really turning that much then something went wrong with the compass readings..looking at the rapidly changing roll, I'd guess that the compass offsets are bad..you can check this by leaning the copter left and right in your hand 10 or 20 degrees..does your compass heading change by more than 10 or 15 degrees?

-Randy

Palo,

     I had a look at your logs a bit.  CTUN is another useful log type to enable as it shows you your altitude and throttle info.  In any case..I'd say your roll and pitch PID values are not great.  Looks like you're getting familiar with checking the logs so you've probably already seen this but attached is your Pitch PID values with the pilot input being in red, the tri's actual attitude in green.  If you check out the time from 25~30, the copter is consistently 30 degrees off of what you're commanding it to do.  I'd say your PID values are far too low.  I'd suggest increasing the pitch rate controller's P value for sure.

     By the way, you can actually turn on PID logging for the controllers them selves.  "logs", "enable PID" then use channel 6 to tune their the stabilize controller or the inner rate controller and it should dump out the P, I and D values into the dataflash and that will give some more details about how well the controller is responding.

-Randy

Randy,

thanks a lot for your interest. When I stared flight I was almost sure the NTUN and CTUN are enabled too  but weren't ;o(

PIDs are taken from somebody from here with tricopter. These PIDs are the first I can flight the loiter with without fear.  When the PIDs are higher my tri in loiter is going crazy and aggressively hunting the position with pitch and roll over 50 or 70 degrees :-o.

Therefore I was glad with such lazy PIDs. But seems they should be really bit upgraded ;o) I have to learn inflight PID tuning, didn't try it yet ;o). But have no much time to going to field, just once per month or so :o(

Anyway the crash is what happened to me more times - tri stopped respond to my commands in STABILIZE and even RTL didn't help. This is the point I must solve otherwise I lose confidence in APM at all. Perhaps it has nothing to do with APM, just battery was too low and APM hadn't enough power to stabilize it, who knows... I can't read it from logs.

With v2.6 and lazy PIDs I was almost happy when the stabilize appeared very good now and loiter wasn't that stressful. AUTO seemed to be OK too but after that I lose the control and scenario repeated.

Anyway since 2.0.49 it is most reliable version of ACM for me.

I wish developers many successes with the code. I'm going to like it since I do small modifications in it and it seems to be more transparent for me now.

Yet another question - how can I achieve faster climbing to next WP?

Scenario : I have tree WPs basically on the same place but middle one has far higher altitude.

I need the tricopter to climb fast to say 2000 meters and then safely dive back to home (just measure humidity and pressure with onboard device in altitude profile).

With my PIDs the climbing and diving to next WP is very slow and with that long flying I'm taking a chance going out of mAh in battery ...

Yeah, I just need confirmation from Glenn, and which mode he likes best.

Sorry I didn't get a chance to try the other options. It was working well with the initial change, so I just stuck with that for today. I'll give the others a go in the morning.

I hope that the developers will solve the issiu on pitch as soon as possible.

Are there other people with the same problem?

Thanks,

Mario

Ok cool, let me know.  I sort of like having the servo move when the motor is off on my heli.  It is of course totally safe, and testing the servo before flight is never a bad thing.  However the question is this:

On the heli, we have a really good setup, such that, the servo won't go beyond it's endpoints, no matter what. For example, if you command yaw on the ground, it doens't actually move, so you have a huge yaw error, thus the servo can move far trying to get it to actually turn (which is impossible because it's on the ground).

Do you have those protections with the Tricopter?  Do you set enpoints for the tail servo? I didn't see them at first look.

If you don't have protection (and it would appear you don't since you had the original problem... ) then I'll have to leave it where the tail servo just stays centered.  And that is what I did, BTW.  Instead of moving to "radio min +300", I have it set to the center, which is "radio trim".

OK I see what you mean now.

On my tri, the servo travel is mechanically restricted by the yaw mechanism before the limit of the servo's movement is reached. There's no endpoint set for my servo travel, so if it was allowed to move when disarmed, when I held the throttle/yaw stick over to the corner to arm, it would be trying to push it past the limit of mechanical movement, and placing strain on the servo.

So for now I think I am happy to leave it so that it stays centred when disarmed. If there was a way to set a parameter to limit the travel of the servo at either extreme in pwm, then I would be more comfortable with it being hard over to the side, since it wouldn't be trying to push past where it was allowed to go.

Changing the min/max pwm values for rc4_max and min would be different though wouldn't it, as that would limit the actual travel of the stick?

Ok Glenn, thanks again.  I'll push it as it is now, and see if I can give you endpoints in the future.  I think it will be straight forward.  It probably won't be a slick setup, just a parameter you have to do manually.  But better than nothing.

Bonjour,

besoin d'aide pour auto trim (APM 1 avec 2.6)pouvez vous me dire ce qui ne vas pas dans ma méthode:

-Dans un hangar (pas de vent),je décolle 

-à 3M du sol (sans plus toucher a l’accélérateur) enclenche  auto trim

- j’essaye de maintenir un assiette stable pendant 1 minute-

-je pose

-coupe CH7 

-j'attends 45 secondes et je désarme

Au vol suivant je suis toujours obliger de faire de minis corrections pour obtenir le stationnaire,coment s'il vous plait obtenir une stabilité parfaite? comment corriger ma méthode?

merci de votre aide

Glenn

  Can't you just move the linkage in further on the servo horn to reduce the throw?

  Bob

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service