Servers by jDrones

Copter-3.6.0 released!

release
stable-release

(rmackay9) #1

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:

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)
  • Tradheli heli users should be aware of these issues (feel free to ask for help in the forums here):
    • 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.

Thanks and if you find issues, please report them in the support forums here!


(Kikislater) #2

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 ?

Sylvain


(tridge) #3

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


(Marco Robustini) #4

Nice job Team, very solid release, thanks everybody!


(Kikislater) #5

Whaooh ! Amazing !!!
I will test it today …


(Marco Robustini) #6

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!


(Kikislater) #7

@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) #8

On a mro pixracer I should not update chibios, isn’t it? Don’t get what does yet, some manual for dummies please.


(rmackay9) #9

@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:


(edge540T) #10

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.


(Nik Barkley) #11

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.

thanks!


(rmackay9) #12

Nik,

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:

  1. 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)
  2. 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.

If you have logs feel free to create a new topic here in the Copter-3.6 discuss forums.


(Nik Barkley) #13

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.


(rmackay9) #14

@Iron_Donkey, fantastic that it’s all working now!


(Marco Robustini) #15

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…


(Hugues) #16

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)


(rmackay9) #17

@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.


(rmackay9) #18

Hi @marco3dr,

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).


(Hugues) #19

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.


(RickyG) #20

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.