Copter-4.0.0-rc2 available for beta testing!

“i) Yaw control fix for fast descent and after large attitude disturbances”: Note in my case the yaw was not related to altitude. tested today and yaw control on my y-6-b is working now but feels a little less responsive. I did get the props rotation a little during arming so i rebooted the battery and it was gone. Thanks everyone time to donate soon. PS never changed the motor that i was thinking the issue was from.

@sergbokh are you using a converter board with a max3232 IC?
When you say restarting the FC you mean power cycling or issuing a reboot via mavproxy for instance?

1 Like

On the Orange Cube, the only way to have Passthru start is by booting with USB power, then plugging the lipo and unplugging the USB.
Haven’t tried 4.0 on anything else, yet.

@yaapu I’m using direct connection pixracer to r9slim+ SPort.
I do restart by power cycle but I will check if restart by MissionPlanner makes any difference.

Is this the same as the RPM filter in Betaflight, which depends on bidirectional Dshot in BlHeli_32, or something else? Is there a write up about the feature?

Sorry @Anthony_Short I should have put in a bit more color. It uses BLHeli telemetry, but only over UART currently. Bi-dir dshot will be supported when we support bi-dir dhot :slightly_smiling_face:


I flew 4.0rc2 with an Y6 and Navio2 today.

There are still two problems so far:
Navio Led turn Green at early startup then turn Off and stay Off…
Oneshot125 is not working: PWM out stay in the 1000-2000 range even if Oneshot125 mode (2) is selected.

I tested Stabilize, AltHold, Loiter, Save waypoint, Auto mode (did the pattern twice in Auto), RTL.

Here is the .bin log

Compiled version from the Ardupilot firmware link doesn’t run on Emlid 2019-02-27 image. Some resources are missing. Compiled version on Navio2 Raspberry is fine.

1 Like

working fine here on pixracer 4.0.0rc2 + X4R.
Do you have an X series receiver to test with? I read about r9slims having issues with the s.port.

Ok, thanks for checking. Yes I have X-receiver, though it will be not very easy to connect to my copter.
I will flash 3.6 first to check if this is a hardware problem with my r9.

1 Like

AC 4.0 RC2 Working great with my Cube Orange. Thanks Randy.

1 Like

@mlebret, thanks for the report on the Navio2 issues. I’ve added them to our Copter-4.0 issues list so they won’t be forgotten.

A similar configuration to @steampunk:

  • Cube Black
  • Here2 X 2
  • Arducopter4.0 rc2
  • gps_type = 9 (uavcan)
  • gps_type2 = 9 (uavcan)
  • gps_auto_switch = 2 (blend)
    After arming attempt (Auto/PosHold) - getting “PreArm: GPS HDOP 655.3 (needs 2.5)”
    No HDOP Indication in any configuration of the GPS_AUTO_SWITCH, nor with a single GPS.
    Log link Attached

HDOP doesn’t get sent over CAN.

It seems that AP_GPS_UAVCAN::handle_fix_msg is not using the pdop field form the fix message. And the Auxilary message that is handled by AP_GPS_UAVCAN::handle_aux_msg is not sent by Here2.

The simple fix is to use the pdop field from fix message for both vdop and hdop.

1 Like

good suggestion, thanks. Fix is here:

1 Like

i ran into a compasses calibration issue - maybe affecting prior releases as well (cant tell).

FC cube black. AC 4.0.0-rc2
my primary (here2) is setup with orientation 0 (yaw 0 deg)
my secondary (BN-880) is setup with orientation 7 (yaw 315)

when i save the config it is all reflected in params as expected (i intentionally have second mag off)


however when i perform on board calibration (using left stick UP-RIGHT or with usb cable via MP - same results) the configuration of the primary changes to ORIENT 7:


i actually flew a mission with this bad config (as i did not spot it initially). copter held the course and completed the 7 km mission but it was rotating 360 every now and then.

I managed to resolve the post-calibration misconfig by physically disconnecting SDA and SCL cables from the second GPS. I have not tested this solution on a mission yet.

Do you have logs for the calibrations you did?

no i don’t. i did however run this multiple times (10?) each time with the same result.

Today, I decided to make a flight in a mountainous town of my country, located at an altitude of 1,100 meters above sea level.

When the drone was flying at the height of 1,200 meters, I started to raise it a little and while I saw the multirotor go up, my taranis x9d plus, showed a height 1,200 meters fixed, without changes, so I decided to decrease the accelerator slowly and reading It still showed 1,200 meters, so when it approached the ground and being at a height of 5 meters, the drone lost power crashing and bouncing up to about 10 meters and then the system activated the landing mode, crashing with the ground again and bouncing about 10 meters, so I decided to lower the throttle and take it with my hands.

I’m not sure if the barometer of my Pixracer is defective, but take a look at the flight log, it could do me good, please,

Some considerable damage, I can still fly again,

It doesn’t look defective me - it and the EKF had a reasonable idea of your altitude:

But I don’t understand why you lost power - clearly this was controlled by the FC as RCOUT 1&2 go to minimum in the period you are talking about: