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!).
The new Firmaware Arducopter 2.6 and Arduplane 2.4 using Chip erase method to clear the dataflash.
Based on my reading on Datasheet of the flash chip, the manufactur (Atmel) mention that Chip erase has intermitent problem and they suggest to use Block erase or Page erase.
Earlier version of Arducopter and Arduplane use Page erase, it was slow but more reliable, block erase should be faster than page erase and still reliable.
Maybe dev team can look into this further cause I guess more people experiencing this issue, I do have this issue happen on some of my APM2 boards.
Thank you for your response Yovi,
I have filed this as an issue in the Arducopter web site.
I could probably use Arduino to go back to the 2.5.5 version of Quadcopter and I still have the .9 Mavlink version of Mission Planner, but since this is obviously a significant issue and since once I put it back to 2.6 I still wouldn't be able to erase I will probably just wait until they fix it.
Major pain to get along without log files though.
I'm not sure if this is the right thread for this or not, if I should post it elsewhere please let me know.
Last weekend I experienced an Altitude Hold Throttle Cut-Out crash and spent most of my evenings this week rebuilding my tricopter. Today I took it out to fly and found that it pulls very hard to the left and a bit harder backward. To fly it, I had to trim all the way to the right and still keep my sticks left and back of center to hover.
Here's what I've done since my crash last weekend:
* Replaced 3 arms
* Replace several broken & mangled frame parts
* Replaced 1 motor (right arm)
* Replaced 1 ESC (right arm)
* Replaced 3 props
* Replaced a broken 3DR radio cable
* Did an erase of the EEPROM on the APM2
* Reloaded the firmware
* Reloaded my PIDs I had working so nicely last weekend
* Recalibrated the ESCs
* Recalibrated the Transmitter settings.
* Did the "Level" thing
* Setup the voltage parameters properly
* Setup the 3DR radios properly
* Setup Flight Modes for my Tx switches
* Checked the Accelerometer & Gyro responses in the Status Tab - a very small amount of noise, but looked OK & responded normally.
* Reset mag declination.
There's probably more, but that's all that comes to mind immediately. Most of the software things I've done multiple times.
Attached is one of my RLOG files from flying this evening. You can see that I'm always pulling to the back and to the left trying to keep the craft hovering. A lot of that is Tx trim, but I had to add more. If you're good with logs maybe you can see something more interesting in there. You'll also probably see that the FC really wants to run that motor on the left, #2 faster than the others - why????
Last week, before the crash, the tri was flying beautifully. I boasted to some friends that the Stable Mode flying was as good as a Naza and I meant it. Tonight it was all over the place, almost like I was in Rate Mode. I had my hand full flying it. I assume this is because the FC wants to do it's Stable magic when it sees the sticks in the center position, which they almost never were. There's no way I'd try Loiter or Auto in the current state. Altitude hold seemed to be OK.
Maybe I'm thinking about this wrong, but for most defects in the frame and drive system, the FC should be able to compensate. I mean if the motors aren't pointing perfectly 90.0000° up the FC will take that into account. Ditto if one motor spins a small fraction slower than the others.
I'm kind of out of ideas of what to try next. I suppose I could replace the left motor and ESC too, but they seem to be providing too much power, not too little. I'll probably do that anyway. The best thing would be to substitute in a different APM2 and see if it responds differently. But I've only got one of them. I wish there were more diagnostics available for this thing.
At this point I will very happily listen to any ideas. Thanks guys!
It sounds like you just need to reset your tx trims to neutral, and then auto-trim it in a windless environment. There's an option to set ch7 to auto-trim, and just use small 'bumps' on the appropriate stick until it doesn't drift much. One you have it sitting pretty stable, turn auto trim off.
That sounds like exactly what I need.
Off to find info about auto-trim... :-)
Bruce, do you power your APM2 with a separate bec?
I say this because with my little quad I had your same problem, because for the first time I have ventured to power my APM2 with the bec of one esc, I never did! :-)
APM2 is very fussy, do not recommend strongly that you power it on with one of the bec inside the esc.
Where is the best place to attach the BEC wire? I first put it on one of the spare ESC outputs but the measured board voltage was very low. I now have it attached to receiver input #8 and the board voltage is exactly 5v.
From what I understand.
The external BEC's output power and ground wire should be able to go to any APM ESC power and ground pin pair.
They should be common bussed.
However, you definitely need to ensure that the ESC's BECs red power leads are all cut.
Although it is often satisfactory to parallel connect the power and ground leads from all of the ESC BECs, you absolutely do not want to mix an external BEC's power with the ESC BEC's power. (You could be mixing switcher to linear regulators and that won't work.)
You DO need to leave the ESCs ground lines connected to provide control circuit continuity.
By plugging into the receiver power and ground you have just picked up another spot on the boards power and ground, but since it isn't designed to power the board, the traces may not be of adequate size for reliable power distribution.
Hope that helps.
I actually believe that good circuit design practices mean you should connect only the signal (white) wire for the ESC. The ground connection is done via the power input of the ESC. Connecting the black ground line to the APM can actually cause a ground loop - this is caused by the "ground" side of the ESC not being equal to the "ground" side of the battery, due to the resistence of the power wires.
I've never understood this on our systems.
My understanding is that a ground loop is caused by differences in ground potential between two circuits. But in our closed systems, all grounds are connected to a single sink - the negative pole of the battery.
If you're using a two battery system, I could see the potential for problems. Or if there was significant different resistance in the ground lines to our components. But how does it occur in a single battery system where all of the components are directly connected to the battery's negative?
I'm just trying to understand this so I can build better systems in the future.
Let me try to explain. The "real" ground reference point is the place where all the '-' lines separate from the single battery '-' line. From there own, each circuit (each ESC, the BEC etc.) draw current through it wire's resistance. This means some voltage differences are created. So the '-' point at the ESC itself is a little different from the '-' reference point. the '-' point at the BEC is also a little different. Now if you connect them together some current is going to flow due to those differences.
So if I understand you correctly, the ESCs are adding resistance between the battery's negative and the ground line the ESC provides on its BEC lines?