Plane 4.0 release


I’m delighted to announce the release of the first beta of the plane 4.0.0 release.
The 4.0.0 release of ArduPilot plane is a major release. It contains thousands of changes, some large and some small, developed over the last year. Key changes include:

  • support STM32H7 MCUs (Durandal and CubeOrange currently)
  • QAUTOTUNE mode
  • in-flight compass calibration
  • support for dynamic node allocation server in UAVCAN
  • support for SLCAN pass-through
  • support for up to 10 battery backends
  • support for MAVLink message intervals
  • initial support for onboard Lua scripting
  • automatic remount of microSD cards
  • support for additional RC input on any UART
  • support for WS2812 LEDs
  • new simulators: Morse, Webots, SilentWings, Scrimmage
  • added AFS_MAX_RANGE for limiting vehicle range
  • added support for @READONLY in embedded parameter lists
  • added SERIALn_OPTIONS for inversion, half-duplex and swap
  • added support for reversible blheli32 ESCs
  • added GPS timing jitter correction
  • added Sum battery backend type
  • added fuel flow battery battery types
  • support landing gear control based on altitude
  • added loiter-to-alt approach for quadplane landing
  • added REVERSE_THROTTLE RCn_OPTION
  • added crow brakes for differential spoilers
  • support newer versions of JSBSim in SITL
  • added RObotis servo support
  • added UAVCAN servo support
  • added failure timer for quadplane forward transitions
  • added KDECAN and ToshibaCAN support
  • added RM3100 compass support
  • support new Invensense IMUs
  • many small improvements to tailsitter support
  • added QACRO mode
  • improved watchdog logging
  • improved EKF compass handling based on WMM data
  • added AP_Periph CAN peripheral firmware system
  • added IBUS R/C input support
  • support yaw from GPS
  • support DLVR I2C airspeed sensors
  • fixed FrSky telem packet loss
  • fixed SUMD for 16 channels via pulse input
  • support UAVCAN buzzers, safety switch, safety LED and airspeed
  • added NTF_BUZZ_VOLUME parameter

There are hundreds of other changes as well. I expect the beta period for this release to be quite long, and I would greatly appreciate as many test reports as possible. Please submit test results both for successful and unsuccessful tests by replying on this topic.

A huge thank you to everyone who has contributed to this release. We’ve had a lot of new contributors and it is great working with such a fantastic community.

Happy flying!

18 Likes

So many awesome feature. No competition comes close to this. Welldone.

QStabilize, QHover with Trirotor-VTOL ( Pixhawk 1) works fine

2 Likes

@tridge awesome, thanks a lot for bringing all that master goodness in!
full aux baro support, BLH_POLES, it‘s all in there, yay!

1 Like

Tested 16 channel PPM/SUMD with a Jetti Rex-7 receiver with Positive PPM and Auto frame length. Works great!

1 Like

well done all
man this project has change so much when i first stared in 2009

@tridge This seems to have broken compatibility with my LW20/C rangefinder.
All was working normally on Plane 3.9.11, using the recommended params here
No longer works after flashing this release (reads only zero’s). Flashed back to 3.9.11 and it works again right away.

are you connecting the LW20 on I2C or UART?
Can you also tell me what flight controller you are using, and which port on that flight controller it is attached to. A tlog of it failing would be good, along with a tlog of it working with 3.9.11.
Cheers, Tridge

@tridge

  • via I2C
  • Pixhawk cube black, with stock carrier
  • Plugged into I2C-2 port
  • Only other peripherals attached are a here2 on GPS1, and a 3DR 900Mhz on Telem1

Hi Blake,

The names of the parameters have probably changed.
RNGFND_xx no longer exists. Did you try it with RNGFND1_xx ?

Rolf

@Rolf @tridge Confirmed it was just that change in param names.
Thanks for the help :slight_smile:

1 Like

I just tested the same setup here, a CubeBlack with LW20 on I2C-2. It is working fine for me.
Key parameters to check are:

  • RNGFND1_TYPE=7
  • RNGFND1_ADDR=102

can you confirm those are both set?

no worries, I replied just a few seconds too soon :slight_smile:

btw, regarding the LightWare Lidars on I2C, one of the new features of 4.0 is that it now talks to native LightWare I2C protocol, which means you don’t need to reconfigure the Lidar for “legacy” access when you buy it.

1 Like

very nice feature added. Personalization should be increased in the on board OSD.

support for additional RC input on any UART

How does that work wrt parameters for? AFAICS both RCs will share the parameters configuration, right?

Also, is the idea that this second RC will be off most of the time to not interfere with the main one?

Is the implementation of precision landing for quadplanes planned for this version?

I talked with the HiTech guys at Intergeo yesterday and they showed me their range of UAVCAN servos. Do you have any experience with them? They claim to have Ardupilot compatibility, but I do not even see how the different actuator functions (servo mapping) should be handled. I would be glad to test, and give feedback.

@vbnhu I have been working with them for a while now. The servos are fully functional with current ArduPilot releases, though I will say development seems to still be active.

The servo mapping is simply taking the effective PWM output channel, shifting by -1 (UAVCAN Actuator ID 0 corresponds to Servo Channel 1) and sending a scaled unitless command packed in a UAVCAN actuator array command. This means that the actuator function (servo mapping) is handled through the normal channels. UAVCAN servos are currently just layered on top of the PWM channel outputs. There is a bitmask to enable UAVCAN outputs within the array command corresponding to particular PWM channels.

There is a programmer (DPC-CAN) from Hitec necessary for configuring their servos, setting up Actuator IDs and CAN IDs, limits, and telemetry settings. The servos do not fully implement some of UAVCAN’s amenities, like editing parameters via UAVCAN GUI or automatic node allocation. The programmer is necessary to overcome this limitation.

A current oddity is that all servos must have a CAN ID matching that of the autopilot (Node ID 10) as they only listen to commands from an identical ID.

Servo telemetry is implemented, mainly providing a 0-100% load indicator. This part in particular is still maturing. ArduPilot does not currently support servo telemetry, so the lack of a matured telemetry system does not have a very great effect yet.

2 Likes

@vbnhu

Correction: while Ardupilot requires ESC index shifting for UAVCAN ESCs due to 0 indexing on the UAVCAN side, the actuators (servos) do not require it. I mixed up the two when writing, my apologies.

1 Like