Warning #1: an issue has been found with Tower's Pause button which can cause the vehicle to fly to an old position if the vehicle has not sent a position update to Tower in some time.
Warning #2: Copter-3.3.2 fixes a bug found in Copter-3.3.1's desired climb rate initialisation which could lead to a sudden momentary drop when switching from Stabilize or Acro to AltHold, Loiter or PosHold.
Warning #3: Copter-3.3.2 fixes an issue found in Copter-3.3.1 which could lead to hard landings in RTL or AUTO if the WPNAV_SPEED_DN was set too high (i.e. >400 or 4m/s) and/or the WPNAV_ACCEL_Z was set too low (i.e. <100 or 1m/s/s).
Warning #4: a bug was found in Copter-3.3 which could cause a sudden crash if you abort a Take-off initiated from a ground station. Video description is here. The bug is fixed in Copter-3.3.1 so we recommend upgrading.
Note #1: AC3.3-rc8 corrected a long standing bug in the HDOP reporting. HDOP values will appear about 40% lower than previously but this does not actually mean the GPS position is better than before.
Note #2: if upgrading from AC3.2.1 the vehicle's accelerometer calibration needs to be done again.
Note #3: set SERIAL2_PROTOCOL to "3" and reboot the board to enable FrSky telemetry like in previous versions.
Note #4: the wiki will be updated over the next few weeks to explain how to use the new features
Copter-3.3.1 is available through the mission planner. The full list of changes vs AC3.2.1 can be see in the ReleaseNotes and below are the most recent changes since AC3.3.
Sadly this version (and all future versions) will not run on the APM2.x boards due to CPU speed, flash and RAM restrictions.
Changes from 3.3:
1) Bug fix to prevent potential crash if Follow-Me is used after an aborted takeoff
2) compiler upgraded to 4.9.3 (runs slightly faster than 4.7.2 which was used previously)
Changes from 3.3-rc11:
1) EKF recovers from pre-arm "Compass variance" failure if compasses are consistent
Changes from 3.3-rc10:
1) PreArm "Need 3D Fix" message replaced with detailed reason from EKF
Changes from 3.3-rc9
1) EKF improvements:
a) simpler optical flow takeoff check
2) Bug Fixes/Minor enhancements:
a) fix INS3_USE parameter eeprom location
b) fix SToRM32 serial protocol driver to work with recent versions
c) increase motor pwm->thrust conversion (aka MOT_THST_EXPO) to 0.65 (was 0.50)
d) Firmware version sent to GCS in AUTOPILOT_VERSION message
a) pre-arm check of compass variance if arming in Loiter, PosHold, Guided
b) always check GPS before arming in Loiter (previously could be disabled if ARMING_CHECK=0)
c) sanity check locations received from GCS for follow-me, do-set-home, do-set-ROI
d) fix optical flow failsafe (was not always triggering LAND when optical flow failed)
e) failsafe RTL vs LAND decision based on hardcoded 5m from home check (previously used WPNAV_RADIUS parameter)
Thanks for your testing!
Yes, it's certainly possible. If the SPI bus is knocked-out (like this appears because both baro and MPU6k go bad) then the board might not boot because we have a "Panic" in the baro driver. We should remove that so the board does boot and you can see what's going wrong with it but that's the way it is at the moment.
When you contact 3DR it might help to tell them that I said that it appears from the logs to be an MPU6k failure.
I did quote you so that they would know what was wrong. Sounds like my log was useful for future development, so that is good. Nobody got hurt in my crash, and hopefully these new functions will make it safer. That is good. Thanks for your help.
Here is the bin file for Mondays flight with better uncontrolled climb and loose Loiter.
Are there any good tutorials on understanding logs? I only understand about 10% of the info.
We can't explain why one shows more clipping than the other I'm afraid but it could be some kind of physical effect of board flexing maybe.
This log is making us re-think whether the solution we put in place after your previous crash did any good. That solution was to de-weight the accels that are clipping but in this case things started going wrong even before they began clipping.
What's unusual about the vibration it is in the horizontal direction. Normally the vibrations are in the vertical direction presumably caused by the motors and propellers but in this case, it's in the horizontal direction which makes us wonder if something is bumping against the flight controller.
1. you don't remember which direction the vehicle leaned in do you? We have two attitude solutions running and they disagree so it's hard for us to be sure which one to believe. You helping us break the tie would be good.
2. Is this a 3DR pixhawk or another manufacturer's board? We don't mind the source of course but it removes some variables if we know.
3. how is the flight controller mounted? Can you provide a picture?
4. if you have a log of this copter flying AC3.2.1 that'd be cool.
Thank you for your kindness and for technical support! (=
I have tried to set up AutoTune Flight Mode.
In mission planner, when I go to the "Flight Mode" screen I can see that there is no AutoTune Flight mode on the drop-down-menù.
So I think that I can not set AutoTune as a flight mode.
There is AUTO flight mode, but this is for automatic waypoint mission.
Is really possibile to set an AutoTune flight mode?
By the way, my Italina friend have found another bug with the rc8. Something about the geotagging of the photos and something about the logging function.
Later he will post here the problem.
Thank you again, have a good day!
Thanks for support. Answers:
1. Lean to left side, you can see MP log in attach (fly from 70% of length of log)
2. It is Pixhack. It have anti-vibration plate inside with sensors.
3. It is on double-sided adhesive tape and attached by buckle (see photo below).
4. I try to fly today or tomorrow.
P.S. You write: "That solution was to de-weight the accels that are clipping but in this case things started going wrong even before they began clipping."
I not very good speak English (as you can see), can you explain what mean "clipping" in this case? It is mean sharp?
GeoTagging and Log problems with rc8
My Italian friend Jacopo have some problems with GeoTagging the photos taken with his multicopter.
He have done some test with rc7, rc8 and some other test by downgrading to rc5.
The problem that his copter have is are the follwoing:
-He can not geotag in the right way the photos (rc5, rc7, rc8)
-The log are wrong. Something very unreadable (rc7, rc8)
-Open the Mission Planner and try to set up a log bitmask type, save the parameters, disconnect from mission planner, unplug the copter, re-plug the copter, connect the planner, and you will see that the log bitmask is not anymore the same. The log bitmask is changed. (rc7 - And also I have this problem with my copter).
Attached a log created by rc8 (Jacopo, since you are reading, tell me if I wrote something wrong).
Here is the link.
I can not upload directly since is more than 7MB
Randy, can you tell what is happened?
Can you tell how to fix it?
I hope this can help with the development.
Yes, it have anti-vibrations palte with sensor, so I can mount it hard on copter and have good level of vibration. But I'm not sure about second IMU unit, it show high level of vibration.
"HDOP values will appear about 40% lower than previously but this does not actually mean the GPS position is better than before."
Does this mean GPS_HDOP_GOOD should be set to 230-92=138 or is it just a display issue in 'Flight Data' ?
Be careful with this setting for HDOP_GOOD, if you activate geofence you will see what factual HDOP and number of satellites it accepts as 'good' until it will finally let drone to arm.
I do suspect a lot of subsequent EKF issues that were reported here may be related to GPS units not yet hooked up to sats at the level that geofence logic assumes to be a good '3D fix'. This '3D fix' level does not seem to correlate at all with what I used to presume as a 'good' HDOP level. It is way, way lower, in the new HDOP values it goes to 12-14 sats and HDOP of 0.90 or something like that. But it flies pretty stable after that.
Seems to be a few problems for us mapping. When using Pix4d to geotag (since mission planner will crash with 3.3 in the geo tagging window), it's not orientating the photos correctly. With camera facing forward selected, the log should assign a kappa angle of 90 degrees. Instead you get like 1 degree which is portrait mode. Don't want to deselect camera forward as it would mess you overlap spacing. It's still possible to map, but it's a workaround.