APM Copter 2.9.1.b has been released to the Mission Planner and is also posted in the downloads area.
2.9.1b is a maintenance release incorporating changes to 4 default parameters that have been optimized since 2.9.1 was released. There are also 4 minor bug fixes. There are no code function changes or additional features.
The changes are:
1) reduce default INS_MPU6K_FILTER to 20hz
2) reduce InertialNav Z-axis time constant to 5 (was 7)
3) increased max InertialNav accel correction to 3 m/s (was 1m/s)
4) reduce yaw_rate P default to 0.20 (was 0.25)
5) bug fix for alt_hold being passed as int16_t to get_throttle_althold_with_slew which might have caused problems if you climbed over 320m.
6) bug fix for throttle after acro flip (was being kept at min throttle if pilot switched out of ACRO mode while inverted)
7) bug fix to acro trainer to do with roll correction
8) prevent cli from being entered more than 20seconds after reboot.
Users are recommended to:
Update Mission Planner to 1.2.41 and
Update their flight code to 2.9.1b from the Firmware tab on Mission Planner. There is no need to go through a new configuration process in the Mission Planner.
Is there any plan on making reading the logs via 3DR telemetry Tx/Rx possible?
I am using the HAL and taking off the dome is not a fast thing.
Randy, are there any news regarding the poor ascending/descending performance? (max. 0.65m/s)
Best regards from Germany,
btw: I've got a strange problem with the geotagging/log.
The log timestamp (tlog and log) is + 5 days. *confused* -> 29.5 instead of 24.5. ls this is a problem of the log or of the missionplanner?
here is a post of my tlog to investigate an issue i had yesterday flying (2.9.1b) in ALT_HOLD: the behaviour was strange : first alt_hold works fine then after a couple of minutes the quad lands as if battery failsafe was triggered. However after disarming and rearming I could fly again and the battery is not empty! This happened a couple of times, weird.
Here is a graph of throttle and VCC which looks strange (VCC has spikes all over):
and attached are my tlog.
additional comment : the second part of the graph corresponds to another battery : strangely enough in that part of the grpah VCC looks normal at 5V constant.
I was testing 3.0.0-rc3 to see if it would detect a missing Magnetometer, I am using an external magnetometer, I disconnected the magnetometer and sure enough it refused to arm and displayed the PreArm: compass not healthy disarmed warning.
BUT it seems to store that fact and never ever again display that message on subsequent attempts to arm it just refuses to arm but will not display the reason.
Even after power cycling the board, will not arm but no message to say why.
When I upgraded to rc3 I did a reset, compassmot and accel calibration now ARMING_CHECK is preventing my hexa from arming?
With ARMING_CHECK set to 0 it will arm and appears to fly okay.
The docs say the following are checked "receiver, accelerometer, barometer and compass" is there some way in Mission Planner or the terminal to figure out which check is failing and why?
I have got a problem to know when my copter is armed or not.
The APM is sitting inside a dome. So it's leds are hard to see. Some time ago I used to fly the mikrokopter which did spin its props when armed.
APM2.5 (and newest firmware) doesn't do anything. No motor-beep, no flashing bright light, no speaker sound.
Wouldn't it be possible to make the software show it's state more visually?
I know this thread is not about Mission Planner however none of this works without Mission Planner which runs very slowly on Windows 7 and Windows 8 unless Bluetooth is completely turned off which is kind of ridiculous fix. It has been reported in other threads. I am just wondering why that hasn't been fixed, does everyone run XP, is Mission planner ever tested on Windows 7 or Windows 8, Windows 7 is not exactly new.I tried all versions going back to 1.2.46 and they all do it
The symptoms are the drop down list for COM Port takes about 30 seconds to do 2 scans. Clicking on Connect, nothing happens for about 30 seconds. Status display most times a lot of readings are 0. Firmware updates fail in a communications error report. By the way that is running on an i7 that runs everything else like greased lightning except Mission Planner. tested on many PCs and Laptops
This may be a daft question, but why do you bother with a magnetic heading when using a gps or inertial, nav as they can navigate with true bearings and not unreliable magnetic ones?
Has anyone used copper mesh shielding under the APM to help reduce EMI with the compass?
Maybe a better question is the magnetic interference caused by the power distribution board (bottom plate on the DJI F550) or caused by the APM being in the same plane as the motors instead of being mounted above/below that plane?