After many months of beta testing, Copter-3.6.0 has been released as the default version for Multicopters and traditional helicopters.
Warning: the battery failsafe voltage parameter is not being properly upgraded from 3.5.7 (or earlier) so it is returning to the default 10.5. Please check the “BATT_LOW_VOLT” parameter is correct for your battery. This issue is resolved in Copter-3.6.1.
Warning2: we have one report of poor main loop performance from a user using the Zubax GNSS V2. We recommend users of this GPS use the ChibiOS version or remain on Copter-3.5.7 until the issue is fully investigated.
Warning3: we have discovered an issue with AUTO mode’s spline waypoints in which the first spline waypoint may be skipped. Fix planned for 3.6.1 which will start beta testing in about 1 week
The full list of change can be found in the Release Notes but here are some of the highlights:
Automatic compass orientation discovery (see COMPASS_AUTO_ROT parameter)
Pilot controlled climb rates configurable in both up and down directions (PILOT_VELZ_MAX renamed to PILOT_SPEED_UP and PILOT_SPEED_DN)
Landing gear and LED colours can be controlled directly from ground station (no GCSs support this yet though)
Battery failsafe supports 2 actions (see BATT_LOW_VOLT, BATT_CRT_VOLT and corresponding BATT_FS_LOW_ACT and BATT_FS_CRT_ACT). Note that if you are unable to modify or update the battery failsafe parameters please try updating the Mission Planner.
flight mode channel can be changed with FLTMODE_CH parameter
auxiliary switches “de-bounced” to avoid transmitter glitches causing false positives
Notch filter allows rate controllers to ignore specified frequencies (see INS_NOTCH_* parameters)
Some notes for those planning to upgrade to 3.6.0:
For Pixhawk family boards, the default firmware uses the NuttX OS but if loading using Mission Planner you may choose to load ChibiOS (a question pops up during the upload). ChibiOS works well but there are a few missing features.
any required parameter conversions should be done automatically meaning there should be no need to manually backup and restore parameters.
no re-calibration should be required except the “Compass calibration required” pre-arm message may appear and force you to re-calibrate the compasses. This is required on a relatively small number of boards which have a compass that we didn’t support in Copter-3.5.7.
NMEA GPS users may need to set the GPS_TYPE = 5. We are forcing NMEA GPS users to set this parameter specifically because we found that a number of UBlox GPSs were being detected as “NMEA” GPSs when it is far better if they use the UBlox custom protocol (UBlox GPSs can output both the UBlox and NMEA protocols but the UBlox protocol has extra data)
Dual users (i.e. chinook style) scaling parameters should be made 5x larger
throttle curve curve has changed and need to be re-tuned before their first use
the following parameters and log messages have been renamed:
ACCEL_Z_ renamed to PSC_ACCZ_
ACC_ parameters renamed to PSC_ACC
POS_ parameters renamed to PSC_POS
VEL_ parameters renamed to PSC_VEL
FS_BATT_ renamed to BATT_FS_
BATT_AMP_PERVOLT renamed to BATT_AMP_PERVLT
PILOT_VELZ_MAX to PILOT_SPEED_UP (and PILOT_SPEED_DN)
RC_FEEL_RP replaced with ATC_INPUT_TC (functionality is same, scaling is different)
WPNAV_LOIT_ params renamed to LOIT_
NTUN dataflash message renamed to PSC
Thank you very much to all the developers who contributed to this release and also to the beta testers who put their vehicles at risk over the past few months and provided detailed feedback! We hope that this testing process, while time consuming, will lead to a much smoother and safer upgrade for all our users.
Hi,
Thank you for this release. Is there an existing material to trigger a camera (like an external relay to get the same property as aux port on regular pixhawk) on omnibus F4 or F405 wing ?
you can use any of the PWM outputs as a relay trigger by setting BRD_PWM_COUNT to a lower value. So for example, set BRD_PWM_COUNT=4, then you can use RELAY_PIN=39 to get relay on output 5
It’s a mistake that I see are doing so many on my Facebook group, so I write here for clarity.
Just update it, don’t load old parameter sets after the update!
@tridge Many thanks !
I have an Omnibus F4 pro v3, so parameters you are talking about is for f405 wing.
So for others parameters to trigger a camera with Omnibus f4 pro v3 is that (tested on arduplane 3.9.2) :
BRD_PWM_COUNT = 2
RELAY_PIN = 15 # for output 5
I found PWM hardware definition here :
So if we want to trigger on pwm 6 we have to set RELAY_PIN = 41. Pretty tricky but when you found how it works it’s really nice !
@edge540T
Feel free to load the ChibiOS version on the pixracer if you like. ChibiOS and NuttX are very small operating systems that runs on the flight controller. They are a bit like the Windows operating system or Apple’s iOS but much much simpler. With older versions of ArduPilot, all the pixhawk family of boards used NuttX but now we also support ChibiOS which is smaller and faster.
It’s unlikely that you will notice any differences when using ChibiOS but underneath ArduPilot is running more smoothly. For example the timing of the main loop (which runs at 400hz) is much more even. Going forward it also allows us to increase loop rates and add more features without changing the hardware.
Tridge did a presentation about ChibiOS at our developers meeting in Canberra in Feb:
Thanks, it’s not so simple, seems a deep reborn for the future, solid one exporting chibios.org work, but I hear drivers word which it fright me a little, I do not really know it must be just windows legacy on my mind. So betaflight recomends fly only gyros and acro to unload mcu and this path seems the other way, the harder one. Thanks again for the job.
Can anyone tell me if you guys have implemented a fix with the issue with the Here2 GPS compass not calibrating in 3.5? Wondering if i should do this upgrade…
I have been trying to get mine to calibrate on QGC and it never would, but i saw someone say that there was a bug that prevented it from calibrating with QGC, so yesterday I re-calibrated with mission planner and shut my internal compasses off… but it was super twitchy and wasn’t holding position very well in Loiter mode… so i recalibrated with MP again, this time with the internal compass 1 on, and now it holds position again… so me thinks the Here2 is still bugged out in APM 3.5 somehow.
Also, any updates to how the cube or MP supports the Garmin Lidar Lite v3?
I’m having the intermittent issue where it “sticks” ? and causes my drone to keep ascending even when I throttle down, and then it will drop rapidly… like it is overshooting my inputs by a long ways… unplug the LIDAR and no issues.
I’m not aware of any issues with the Here2 GPSs not calibrating. Normally it’s not the external compasses but rather the internal compasses that cause trouble. We have some advice here on the wiki but it short it comes down to trying two things:
increase the fitness value to “Relaxed” or “Very Relaxed”, if QGC doesn’t show this option then try directly setting the COMPASS_CAL_FIT to 32 or even higher (like 50)
if you’re sure you’ve got the external compass oriented correctly set COMPASS_USE2 = 0, COMPASS_USE3 = 0 to disable the internal compasses. Becareful though because this removes AP’s ability to do the pre-arm check that the compasses are pointed in the right direction.
We’re planning to add support for the Garmin LIdarLIte v3 in 3.6.1.
Hi Randy,
Thanks for that, I actually got the compass on the HERE2 to calibrate today, it only did so after I upgraded to APM 3.6
After the upgrade I re-calibrated along with disabling the internal cube compasses and it flew just fine again as far as I can tell, and also no longer has a MAG variance error in the log,
The LIDAR actually worked today as well, not sure what changed to make it happen but I flew it around 3 times today and it worked well.
Warning: after the update check the battery failsafe voltage value, many after flashing 3.6.0 found it at 10.5V, and with configuration at 4S or higher is not pleasant thing…
About the 3.6 (ChibiOS) support for new boards, are there any F3 boards that are supported ? (if not is there a reason why only F4 or higher boards are only supported)
@Hugues, AP can at least theoretically run on the F3 boards but I think the issue is that they have small very flash space (flash is used to hold the software itself) so we need to chop a ton of features from AP to make it fit. I think that one of the non-GPS Skyviper drones uses an F3 but it can’t even do Loiter mode. I think the F3 boards have about 512MB of flash space.
Re the battery failsafe voltage, I’ve confirmed the older 3.5.7 parameter (FS_BATT_VOLT I think) is not being copied over to BATT_LOW_VOLT. This seems like a bug to me so I’ve added it to our issues list and I hope we will fix it for an upcoming point release (maybe 3.6.1).
thx, very understandable explanation. It is a pity these F3 lack flash/ROM space as I have plenty of unused F3 boards on my shelves…Oh well, I’ll have to renew hardware again.
Anyone out there running 3.6.0 and a Zubax GNSS v2 GPS and have it working. If so any chance you can kindly share your Param file for your working machine. I would like to compare it against my machine to see if I have missed something in the config as I am not able to get the GPS to work yet it’s confirmed now as a functional GPS.