WARNING: do not attempt to upload the bootloader with Copter-4.0.0-rc1 to -rc4 on any H7 boards (these are high powered boards like the CubeOrange, Durandal, CUAV V5 Nano) or you risk “bricking” your board. A fix will be released with Copter-4.0.0-rc5 tomorrow.
Copter-4.0.0-rc3/-rc4 has been released for beta testing! If you’d like to help us with beta testing please use the MP or QGC’s “Beta Firmwares” link to download this latest version or alternatively the binary can be downloaded directly from firmware.ardupilot.org
There are a large number of changes which are listed in the ReleaseNotes and also copied below:
- Flight mode and control improvements:
a) Auto mode Takeoff getting stuck fixed (very rare)
b) AutoTune protection against ESC sync loss at beginning of a twitch
c) SystemID mode parameters hidden by default (set SID_AXIS to non-zero to see all)
d) Takeoff from slanted surfaces improved by reducing I-term build-up in attitude controllers
- Lua Script related enhancements:
a) MAV FTP support to ease uploading and downloading Lua scripts
b) NeoPixel/WS2812 LED control from Lua scripts
c) Pre-arm check that Lua scripting feature has enough memory
- TradHeli enhancements:
a) Autonomous autorotation (compile time option, not available in stable firmware)
b) CCW Direct Drive Fixed Pitch tail support (see H_TAIL_TYPE parameter)
c) Parameter description improvements
d) STAB_COL_1/2/3 param range changed to 0 to 100 (was 0 to 1000)
- Lightware SF40c driver for latest sensors with “streaming” protocol
- Board/Frame specfic fixes:
a) Hex CubeOrange IMU heater control gain tuning improvement
b) Holybro Durandal IMUs ordering fix so EKx_IMU_MASK bits are intuitive
c) Holybro Pixhawk4 B/E LED fix (was flickering)
d) MatekF765 PWM outputs 5 and 6 now functional
e) MatekF765, MatekF405 time wrap CRITICAL fix for vehicles flying more than 72min
f) MatekF765 LED fixes
g) mRobotics ControlZeroF7 I2C bus numbering fix
h) Solo default params updated for 4.0.0
i) Bootloaders for boards using STM32H7 CPUs
j) Bootloader protection against line noise that could cause the board to get stuck during bootup
k) LED timing fix for FMUv5 boards with LEDs on one of first four auxiliary PWM outputs
- Minor Enhancements and Bug Fixes
a) I2C storm High level protection
b) Internal errors (like I2C storms) reported to GCS by setting Heartbeat status to Critical
c) Dataflash Logging CTUN.TAlt and SAlt scaling fixed
d) DO_DIGICAM_CONTROL messages are sent using Mavlink1/2 as specified by SERIALx_PROTOCOL
e) DO_SET_SPEED sanity check fixed to protect against negative speeds
f) FrSky telemetry scheduling improvement (fixes issue in which GPS data would not be sent)
g) GPS auto configuration fix for non-Ublox-F9 (F9 config was interfering with other Ublox GPSs)
h) Landing gear DEPLOY message fix (could be displayed multiple times or when gear not configured)
i) Pre-arm check of position estimate when arming in Loiter even if arming is “forced”
j) Pre-arm check that Terrain database has enough memory
k) RangeFinder parameter conversion fix (some parameters were not upgraded from 3.6.x to 4.0.0)
l) RangeFinder TYPE parameter descriptions clarified for LidarLite and Benewake Lidars
m) Serial parameters hidden if they do not exist on the particular board
n) UAVCAN GPS fix for GPSs that don’t provide “Aux” message (like the Here2)
o) NMEA Output bug fix (output was stopping after 90 seconds)
Update: Copter-4.0.0-rc4 has been released which just has three small changes over -rc3:
- Compiler updated to gcc 6.3.1
- Solo default parameters updated
- Bug Fix to RCMAP channel number sanity check
We are hoping to release 4.0.0 as the official version in as little as 1 week so we would greatly appreciate some rigorous testing to help us uncover any remaining issues. I plan to respond to as many posts as I possibly have time for over the next week.
If we do manage to get Copter-4.0.0 out next week (or soon after) this will have been a shorter beta period compared with previous major release (for Copter-3.6.0 we did 12 release candidates) but we plan to follow-up fairly soon after 4.0.0 goes out with a series of smaller point releases to address issues that turn up in newer features like BendyRuler.
Thanks again for helping us with beta testing this major release!
Does it get updated by itself, or do I have to Ctrl-F / update bootloader ?
Any chance to have support for RM3100 in before the stable release?
Great work as usual!!!
So far, on the desk, Orange Cube starts spewing out FrSky passthrough when powered by LiPo \o/
According to Tridge, the bootloader is included in all firmwares so it shouldn’t be necessary to do anything beyond loading the beta firmware on the board. Txs for helping us test!
The RM3100 compass is apparently included in Copter-4.0 (code is here) so the basic driver is there at least. Can I ask which board are you trying to use it with and is this via UAVCAN or I2C?
uploaded on a test copter, everything seems to go extremely bad. Gps glitches all over, ekf fsailsafes. use to run this copter on 3.6 with no issues. 4.0 RC3. using an m8n on pixracer
Will the traditional helicopter L1 navigation mode be integrated into the 4.0 stable firmware?
@zhangsir, I don’t think it will be integrated into Copter-4.0.0 because we’re not planning any further enhancements before the 4.0.0 release. It’s probably best if I leave it to @bnsgeyer to say what the future plans are for TradHeli.
Thanks for giving 4.0.0 a try. I’ve had a look at the logs and a few things:
- The GPS doesn’t seem very happy with a lot of drops in the satellite count and jumps in the hdop. Is there anything that is placed very close to the GPS? Perhaps a high power telemetry system or a companion computer?
- the GPS_AUTO_CONFIG has been set to zero. Normally it’s best to let ArduPilot configure the GPS so that it gets all the messages that it needs. I wonder if you’ve disabled this in order to force the GPS to 10hz? It “yes” then this is not actually an improvement and results in an uneven update rate. Could you restore GPS_AUTO_CONFIG to the default of “1” and try again?
- the LOG_BITMASK has been modified so the CTUN message doesn’t appear. This makes it difficult to check the altitude hold performance and the throttle’s impact on the compass. Any chance this could be returned to the default which I think is 176126.
ok, set the gps to autoconfig, and logs to include ctun, ill test it in the morning in the same condition.
@zhangsir thanks for your interest in the L1 navigation implementation into Arducopter. It would be nice to have that in AC 4.0 but would require significant effort on my part to make it compatible with AC 4.0 or even Master. Currently I am devoting my time to making a smooth transition to 4.0 with the huge number of features Chris and I added over the past year as well as improving the documentation on tradheli setup and features.
I had a quick look at one of those logs. Basically only the GPS number of sats was all over the place.
The Vcc 5 volt supply to the flight controller is poor. Your power brick output is following the battery voltage up and down and is acting more like a voltage divider than a regulator.
The voltage is not going critically low for the FC, but it is suspicious. Maybe by the time the 5v makes its way through a couple more connectors to the GPS it is too unstable and low for the GPS to work reliably.
I cant say for sure if that powerbrick (or wiring) is the cause of your GPS problems, but I’d be getting a new one anyway.
The other thing to try is downgrading to the previous firmware but I don’t think that will help except to rule out (or in) the firware version as being the problem.
Uploaded Copter-4.0.0-rc3 on my test pixhawk aircraft. Mission planner pushed fmuv2 firmware automatically. I noticed ATC_THR_MIX_MAN changed from 0.5 to 0.1 compared to my AC3.6.12 param. I also noticed ground effect compensation was set to 1. Are these made default?
Flight had no issues. I’ll attach the log below.
Let me if anything has to be tested specifically.
Yes, One more thing i noticed was how GCS failsafe is triggered. Usually GCS failsafe never used to trigger if there is good radio connection. But this time it triggered every time i closed my GCS app. Is this being updated?
Thanks but as far as i understand it doesn’t get enumerated so it doesn’t work.
The DroTek F9P Sirius GPS uses the RM3100 as an I2C device:
There is an outstanding pull request to fix an i2c probe issue with the RM3100 driver:
Thanks very much for testing and providing feed, it really helps.
The parameters changes to ATC_THR_MIX_MAN (from 0.5 to 0.1) is intentional and was made by @lthall (here’s the commit). Leonard would know the reason better but my faint memory is that this is a safety improvement and protects against “climb aways” for very badly tuned vehicles.
The GND_EFFECT_COMP change (it is always enabled by default now) is also intentional. Although many copters do not need ground effect compensation we have so far never seen any negative effect for having it enabled.
The GCS failsafe has also been greatly improved (we hope) since Copter-3.6. It now acts just like the telemetry failsafe in Plane. The vehicle should RTL if the telemetry link is lost. My only concern is that it is enabled by default and some users may get caught either being unable to arm or experiencing a failsafe when they wouldn’t have previously. I guess what I’m saying is that I’m pretty confident that the GCS failsafe is improved but we may need to disable it by default if it annoys people.
I had a look at the logs and it looks like a well tuned vehicle, nicely done.
Thanks again for the report!
@Corrado_Steri, @rrr6399, OK, thanks for that. It looks like Tridge had another look at it about a week ago but we just need some (probably minor) fixes before it can be merged. I’ve added it to the Copter-4.0.0 issues list so it won’t be forgotten and will most likely be included in 4.0.1. Sorry, we’ve missed the cut-off for Copter-4.0.0 I think unless something serious turns up and we need to delay the 4.0.0 release.