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]
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!).
nicely done duran.....
Yes yesterday I tested the new 2.6 and I had the same effect. Only switching to ALT Hold in about 15 meter and the T-Rex 450 dropped out of the sky. It worked well before the change to 2.6.
I just flew a pack with 2.6. I found it well. The loiter was a bit better but still needs some tuning on my part. I found the stability was much better with 2.6 than 2.5. It might be a placebo type effect but I found my copter handled wind better.
For anyone getting the Mavlink error, there are two executable files. The one with 10 in the filename is the Mavlink 1.0 one.
I had a similar tri, I've attached the .param file. Open with a text editor and you will find the PID's.
I've read the wiki, and the first thought that I have when my buddy crashed mine is he was still in Alt Hold mode.
I'm not demanding or complaining, I'm working as developer my self so I'm getting iritated when my user become demanding :)
I was tryin to understand why can't we have a code that stop the motor when throttle reach its lowest position, maybe this has been discussed by dev team earlier.
I understand that in Loiter & Alt Hold Arducopter control the altitude based on relative barometric pressure and on uneven terrain this can be a problem.
@airmamaf: Thank you for your idea to have a safety switch program this way :)
Once again I'm not complaining that my quad was crash, it was just 4 props. All my motivation is so we can improve arducopter. I will try to look at the code more on this part to understand all the condition and consideration.
I think I remember sometimes back someone talking about pressure(force) sensor mounted on the leg to detect landing condition.
I'm afraid the answer is: it depends
There are different boards - APM, APM2
Each board has more than one way to power it, and each way to power it can handle different voltages and different amounts of current.
I think you mentioned APM2 in another post, so let's talk about that one.
"Therefore, power requirements are as follows: 5.0VDC +/- 0.5V supplied into the PWM input connector, jumper JP-1 removed. 5.37VDC +/- 0.5v supplied into the PWM output connector, jumper JP-1 in place"
"APM2 by itself draws relatively little current (200ma range)"
The same page suggests that the board is well within design specification if your total draw is 500mA, so that gives you at least 300mA to handle the telemetry, RX, and servos before you add LEDs.
That page does not list the maximum current allowed.
But there is more information at http://diydrones.com/forum/topics/problem-with-apm2-powering-up-my-... and Craig Elder's comments are the most helpful.
So that means something like:
APM2 with JP1 - 500mA max
revised APM2 (soon) with JP1 - 1A max (and better circuit protection against shorting the input pins; a fuse to prevent blowing the diode)
Remove JP1 and power input and output rails separately - I don't know... I need to look at the schematics. But if 500mA is not enough, you almost certainly want to do this
There are folks here who are much more qualified to answer this question than me :)
John beat me to it whilst I was sleeping. No need to disable logging as this is done automatically when you select 1280 as the board in Arduino IDE. Another line for the config.h is #define GPS_PROTOCOL GPS_PROTOCOL_MTK16, saves another 5.9k.
Unfortunately it gives the problems I had above even though it compiles fine. I don't know when it was last working as I haven't flown since about 2.2. When I used this line in 2.5.5 I only got as far as doing setup over USB, never went flying which is why I didn't see it earlier.
It has been listed as issue #392 back on 16/3/2012 and looks like it affects ublox as well.
It would be nice if someone smarter than me could take a look at this as there is only 3.17k left on the 1280
Wouldn't that be dangerous?
Consider the situation where Alt_hold is in use, and the user's intent is to decent. Perhaps the quad is at 400 feet AGL. The user pulls down on the throttle, intending to back it off from 1/2 to 1/4, but pulls it all the way down instead. The motors shut off.
Now, it is my understanding that, depending on how the ESCs are made, and depending on how they are configured (break or no break, etc) this may be a fatal problem for the quad (and, hopefully not for anyone on the ground.) I was once told that if the motor auto rotates (which is likely to happen when the motors stop spinning on their own) and start free spinning, it can sometimes be impossible for the ESC to stat spinning the motor again, because (depending on how the ESC was made) the ESC needs to sync with the motor and cheaper ESCs cannot do that with a motor that is already spinning.
I'm not an expert with ESCs, so it may be that I have something wrong there...