Copter-4.0.1 released!

ArduCopter Copter 4.0
1

Copter-4.0.1 has been released as the official firmware for multicopters and traditional helicopters!

The changes vs 4.0.0 are in the ReleaseNotes and copied below:

  1. FrSky telemetry status text handling fix (Critical Fix)
  2. Circle mode allows pilot control of radius and rotation speed
  3. CAN servo feedback logged
  4. Magnetic declination tables updated
  5. Serial0 protocol forced to MAVLink (avoids accidental disabling of USB port)
  6. Minor Enhancements:
    a) Autorotate flight mode renamed to Heli_Autorotate
    b) Solo default parameters updated
    c) “Prepared log system” initialisation message removed
  7. Bug Fixes:
    a) TradHeli RSC RC passthrough fixed
    b) CubeOrange and Durandal I2C timing fixed (was running slow)
    c) Compass calibration auto orientation skips “pitch 7” which could cause cal to fail
    d) Durandal’s fourth I2C port fixed
    e) Linux boards with CAN support fixed
    f) Neopixel added to SERVOx_FUNCTION param description
    g) NMEA Output fixed (was sending an extra CR)
    h) Optflow messages sent even if EKF has no height estimate
    i) SkyViper build fixed
    j) Spektrum/DSM 22ms RC input fixed
    k) “UC Node Down” message removed (was unnecessarily scary)
    l) Semaphore fixes for Logging, Filesystem and UAVCAN Dyanmic Node Allocation
    m) RangeFinder parameter fix (4th rangefinder was using 1st rangefinder’s params)
    n) TradHeli STB_COL_x parameter description fixed

The most important change is “1) FrSky telemetry status text handling fix (Critical Fix)” which resolves the critical issue announced in this blog post.

WARNING: we have seen two reports of CAN compasses not being recognised at startup unless BRD_BOOT_DELAY is set to 5000. This parameter slows down the autopilot’s boot time (by 5 seconds) which gives more time for the CAN peripheral to startup. This is not a critical “bug” that should lead to crashes but we would like to hear from users if they are having troubles with CAN compasses being detected.

Special thanks to our beta testers for testing this release over the past few weeks. You are a critical part of the process and we really appreciate your help! Thanks!

11 Likes
3

thank you so much for all the work you do for us Randy

1 Like
4

@rmackay9, you ment BRD_BOOT_DELAY parameter ?
Gal

1 Like
5

Thank you for your hard work randy and other developer who involved in this release.
By default this value is BRD_BOOT_DELAY is 0.

As you said randy dynamic Alt change and dynamic ground speed change in auto mode will work in AC 4.x release.

But I have tried many times it’s not working at all,When I go extended tuning parameter page and change wp_speed to what ever value then only it take effect.

In auto mode there is no stop and turn method even AZ degree goes above 90 degree from current heading but sometimes it does I don’t couldn’t find the reason. Whem does it will make stop and turn and bank turn (current method) it use roll as well about 13 to 15degree to achieve within this desired point. But it looks sometime very Stanger.

Please give me some feedback to over come this issue.

6

Good day, ive install today the version 4.0.1, ive a drotek r3100 wired on mro can bus on the i2c after the calibration the rm3100 its not recognize, setting the boot delay as you adviced but nothing happened.
I did not find the same issue on version 4.0.0.
i will attach the log25.01.2020.bin (283.5 KB)

7

Mav FTP, on pixhawk 2.4.8 is not working. In ‘dev’ firmware ftp is working(from https://firmware.ardupilot.org/Copter/latest/fmuv3/), but there are down some other fings, like radio control with telemetry, heh it can’t fly in one word.

9

@gnitzan, yes, thanks for the correction, I’ve updated the notes!

10

@kalai1219,

Re dynamically changing the target ground speed, there appears to be an issue in the Mission Planner which I’ve raised an issue for here. I’ve tested the flight code with the MAVProxy GCS and it seems fine so pretty sure it’s a mission planner issue.

Copter doesn’t support dynamically changing the altitude during missions. There’s already a request on the issues list covering this but I can’t promise when we will get to it.

Re “stop and turn” in auto mode, I think you’re referring to this long standing issue re copter’s navigation algorithm. For now the best advice we can give is to add a delay to the waypoint (set the first parameter to 1). In a future version of Copter we will include Leonard’s S-curves navigation which will make things better.

1 Like
11

@Dave84,

There was an issue with the build server which meant that Copter-4.0.1 didn’t go out at the expected time. It’s out now but from looking at the log you’ve provided the vehicle is still on 4.0.0. Perhaps something else has changed in the setup to cause the rm3100 to not be recognised?

12

@Kowal666,

I’ve just checked MAVFTP using MP with a CubeBlack running Copter-4.0.1 and it appears to work. I press Ctrl-X and then I can open the APM/TERRAIN folder and see some .dat files in there.
image

I wonder if perhaps MAVFTP is not available on the fmuv2 builds and that this is what is being loaded onto your board if MP’s firmware install screen is used. The firmware that is being used is shown in the messages sent to the GCS soon after a connection is made. For example below is a screen shot showing that I’ve got the CubeBlack on my board. Can you confirm you have the fmuv3 firmware on your board when MAVFTP is not working?
image

Another possibility is an issue with MP (or whatever GCS you’re using) although this seems unlikely because you’ve confirmed it does work with Copter-4.0.1-dev.

13

@Corrado_Steri, @rrr6399,

If you have a moment I was wondering if you could confirm that the rm3100 (present on a DroTek F9P Sirius GPS unit) is working for you with Copter-4.0.1? I think you’ve confirmed it was working in Copter-4.0.0-rc4 so it should still be working but if you could double check that would be a great help, txs!

1 Like
14

It was working in the latest 4.0.1 Dev build which was post rc3. I will be upgrading mine tonight to the stable 4.0.1 and I will confirm it works. The only difference and not sure it matters but my rm3100 is on the can bus

1 Like
15

Good day, the setup didn’t change… rm3100 is connected on i2c port of can nodri will flash again the firmware and i will check if the rm3100 will be recognized… i will let you know

1 Like
16

I just tested 4.0.1 on both a Holybro Pixhawk 4 mini and a CUAV V5 Nano and the rm3100 compass got picked right up no problem… This is in the CUAV NEOV2 Pro CAN GPS with RM3100 Compass. I am not sure if I2C is different

I will try to get this loaded on my CUAV V5+ Cube tomorrow to see if the results are the same

1 Like
17

I am sorry but i don’t have a machine with 4.0 with rm3100 installed :frowning:

1 Like
18

I have had some worrying problems with the AC 4.0.1 which could lead to crashes.

Please check the topic below:

19

I have seen parameter FRAME _TYPE to many configuration and also seen 13 DJIX.
This means motor order and connection also will differ?
Because DJIX configuration is start from right top motor 1 and counter clockwise its 2, 3 4 respectively.
But where as arducopter is different.

20

@kalai1219,

Looking at the AP_Motors library it seems like our “DJI X” frame is setup to order the number in counter-clockwise as shown here. In my (limited) experience with converting a DJI hexacopter to use AP, the motors were in clockwise order so I tend to agree with you. Do you have some reference that shows the DJI motor order is clockwise? This would help with the discussion to possibly have it changed.

21

Dji motors order are always start with front right motor and counting towards its counterclockwise direction. It’s not clockwise direction.
One thing I have noticed in AC hexacopter when do YAW command from RC remote some motors are almost it reach stop condition (very low rpm and we can see it in our eye’s also).
But in case of DJI motor order I didn’t see such different why?
There’s any special reason for putting motor order in different way in AC.