ACRO bug (fixed in 2.9.1b): while doing flips in ACRO mode, if you switch to Stabilize while inverted your throttle will go to minimum. To regain throttle control you need to switch back to ACRO then back to Stabilize again (i.e. switch to stabilize twice). You never lose control of roll/pitch/yaw.
Loiter/AltHold/Auto/RTL bug: if you switch into these modes with throttle at zero motors will go to minimum until you raise the throttle.
Auto mode altitude bug (fixed in 2.9.1b): setting a waypoint altitude greater than 320m over home altitude may wrap around and instead be interpreted as a low altitude.
ArduCopter 2.9 is now in the mission planner and the downloads area!
The major improvement is we use inertial navigation to improve altitude hold. This increased reliance on the accelerometers means you must do some additional set-up before flying:
3. If upgrading from 2.8.1, modify the throttle and altitude PID values:
Here is the list of major changes (a more detailed list can be found in the release notes):
As per usual 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.
Special thanks to our testing team lead Marco and the dedicated bunch on the 2.8.1 release thread who put their copters at risk while testing the pre-release version. Some of their videos are here: 1 2 3 4 5 6 7 8
Please feel free to report issues you find in the discussion below and/or add them to the issues list.
Sorry about your mux, I fried mine on my APM2. It was caused (I think) when I caused a momentary short on the power supply resulting in a spark. I don't know why this caused the mux to let go but I can only guess that this chip can be a bit sensitive somehow. But I am not sure if I wired up my osd wrong or something and the timing of the short was just a coincidence.
Sucks when stuff like this happens!
Thats what i dont get
no shorts not osd just had usb and 900mhz plugged in at the same time.....
surely that should not fry the chip.
would it be best to maybe route 900mhz to uart2 permanently to avoid this in future.....
oh well i guess thats it then....rs electronics thankfully have
in stock and i have access to a smd rework station at work will replace it and see failing that i may even go far-out and remove the mux and bridge the pins for usb only .....at least it will be usable....kinda.....might then work with 900mhz on uart 2....will have to have a close look at the eagle files....and see
and for heavens sake can someone please make a bold note in the manual so that no one else gets these plug in at the same time.......and fry their hard earned cash on something thats not explicitly documented.
this is all that is said
Important note: You cannot connect via the radios when your APM 2.x is also connected via USB (they share the same port). Make sure you disconnect your USB cable from the APM 2 board before attempting a wireless connection.
maybe something like to connect usb and wireless telemetry YOU WILL FRY YOUR MUX IS MORE APPROPRIATE
Theo, I have had some stuff fried due to power spikes. I'm now going to use a
http://www.pololu.com/catalog/product/750 for the FPV gear and
http://www.pololu.com/catalog/product/751 for APM and related equipment.
However: I have NOT flown with this yet and YES it adds another level of complexity.
Last time this happened, it fried the APM2.5, uBlox and MinimOSD all at the same time. All connected to the 3DR provided power module.
But, I have down to 2.8.1 is Altitude value normal.
I routinely have both my 3dr 900mhz plugged in at the same time I am using the usb port and so far I haven't had any problems. I know you can't use the port for both at the same time but I haven't seen adverse effects on the apm. As Leonard said, all it takes is a micro second of bad connection and you may not even notice an arc etc. If the 3dr radio can cause this problem it should indeed be noted somewhere.
I could be wrong, but when you are in loiter mode the apm does all of your leveling etc to maintain position, so I would think you would see pitch and roll inputs that the apm is providing to maintain position etc.
Tim, I had this reply from Randy a few weeks ago
You can graph Roll-In vs Roll and Pitch-in vs Pitch in the dataflash logs. The Roll-In and Pitch-In is actually a mix of the pilot input and autopilot-input so it can always be compared to the Roll and Pitch columns that appear next to it in order to see the actual roll/pitch vs desired roll/pitch.
the downside of us mixing pilot and autopilot roll/pitch into Roll-In and Pitch-In is that we then need to subtract the nav_roll and nav_pitch from the roll-in/pitch-in to see what the pilot was doing during rtl, loiter, missions, etc...but ... that's the way it is at the moment.
Tim, pitch and roll in logs are the sum of pilot and nav controller inputs. The current 'sum of inputs' logging is useful for tuning (that is what the control loop sees). However without isolated pilot and/or nav input logs, depending on the circumstances, it can be impossible to differentiate a GPS failure from a control tx/rx failure. I discussed a similar 'ambiguous failure' I had several weeks ago with Randy. He mentioned the possibility of adding an isolated input log, but it didn't appear to gain much traction for 2.9.2.
maybeThe Free Dictionary: An uncertainty: There are so many maybes involved in playing the stock market. →
What compass offset values are acceptable? I'm just getting initial tuning done on my first quad...it's built with aluminum arms but does have steel machine bolts. The APM and GPS are about 2 cm above the power distribution board and ESCs. The compass offsets from one of the first flights are as follows.
COMPASS_OFS_Z: -370.408260 - the Z looks quite high.
Log file is below...
One of final tests... Waypoints, Loiter, Guided mode, one of the most impressing Circle auto WP with ROI. Great job guys!
OK - Attached is a picture of the APM mounting on the quad. I also did the live calibration - and - tada - no large swings of the compass at full throtte! That was with no changes to the physical configuration of the quad itself...
So - that's pretty strange.
I attached a screenshot of me manually orienting the quad in four directions and going full throttle on each direction. Each of the positions shows a nice flat yaw angle...
Good news Rich.
I would however also suggest that your APM is still quite close to the power lines, could you rearrange your standoffs so that the APM was a cm or two further away from the PCB, that would ensure your improved results. Or an external mag on a top plate above your reciever. Or some mu-metal just above the PDB, if you've been following that thread.
Also, with any luck, in 2.9.2 we will be able to compensate for the fields generated by motors current draw with a very nifty little calibration proceedure that Randy, Jonathan and others have come up with. As always, watch this space :)