Copter-3.6.0 available ("soft" release for 2 days)

ArduCopter Copter 3.6
,
1

Copter-3.6.0 has just been released but will only be available through the Beta Firmwares link until Monday. From Monday onward it will becomes the default version (assuming no last minute issues).

The changes vs -rc12 are listed below and are also in the ReleaseNotes:

  1. Bug Fixes:
    a) Object avoidance fix when using 360 Lidar (mini fence was not including first distance)
    b) Flowhold mode descending fix
  2. ChibiOS related fixes:
    a) Kakutef7 support pin mapping fixes
    b) PixRacer LED fix
    c) I2C Lidar driver fix to avoid freeze at startup if sensor not connected

Any final testing people can do before we go live is greatly appreciated!

Note: there are still a few issues that we will address in follow-up “point” releases (i.e. 3.6.1, etc). The most serious is bad loop timing if using Zubax GNSS2 via CAN so for now we recommend users of the Zubax GNSS2 via CAN, use ChibiOS builds.

Thanks very much to all the beta testing done in this group, it really helped a lot!

9 Likes
2

Is the bad loop timing with zubax only effecting Nuttx? Are we ok if using 3.6 ChibiOS?

Corrado

3

Thank you Randy and the team,I love this keeps my old brain cells active cant wait for new features as you all ways pull a lovely rabbit out of the hat.

3 Likes
4

Corrado,

At the moment, it appears the bad timing when using Zubax GNSS2 via CAN is only affecting the NuttX build. To keep things simple though I’m recommending people stay on 3.5.7 if they are using one of these GPSs until we figure out the cause.

5

Just for reference i have about 15 hours flight time using 2 Zubaxx Gps on canbus using 3.6 RC12 ChibiOS without any problem.

Corrado

1 Like
6

The commit for the pixracer LED fix appears to say NuttX but the release notes say ChibiOS - which is it? :slight_smile:

7

I can add a similar scenario, two vehicles with no issues using Zubax UAVCAN and ChibiOS. In fact I have a bit better results overall compared to Here gps in similar equipment.

Cheers, RB

1 Like
8

So I tossed 3.6 on to my Pixracer and started testing on the bench this morning.
I could be wrong but I don’t think the LED color situation has been corrected. It still shows red flashing when the safety switch is pressed a solid red when armed. I think thats wrong.
Pretty sure that solid Red is an error and there is no flashing red.
The external LED I think is working right color wise…When it works.
Here is a video showing the testing this morning.

Also here are some logs which are showing some weird stuff on the power graph

also at the end I got these errors all of a sudden
bad ahrs
bad pos variance
bad gps signal
5 1979-12-31 7-00-00 PM.bin (233.2 KB)
4 1979-12-31 7-00-00 PM.bin (573.8 KB)
3 1979-12-31 7-00-00 PM.bin (681.9 KB)
2 1979-12-31 7-00-00 PM.bin (658.5 KB)

9

Very strange behavior of GPS Prearm check in 3.6.0:
As soon as the number of sats locked increases beyond somewhere 20-22 sats with my UBLOX m8n, I get a “Prearm GPS not healthy” message in my GCS and can’t arm. It continues to flicker on and off within seconds. As long as the number of sats locked is lower, everything is fine.
Never encountered such problem in AC 3.5 and earlier versions with the same setup and parameter setting.
Details and logfile here:

1 Like
10

I can’t get off the ground with 3.6 - I get “PreArm check: compasses inconsistent” the whole time. rc12 was fine. I see this inside as well, occasionally the compasses are completely fine at boot, but most of the time show red bars in the EKF dialog with that warning. Caveat: my compass situation is less than ideal, so it could just be me.

11

FYI: Flew my 450 quad with mRo Pixracer. Once with NuttX and once with ChibiOS; both with 3.6.0 upgraded from 3.6.0.rc7, today. No issues: Stab, AltHold, Loiter, Circle, PosHold, Mission ,RTL, Low batt FS with RTL. All worked Great!
Fantastic job- Thanks for all the effort put into this release.
Joe

1 Like
12

@rmackay9, I Don’t think this is a 3.6.0 problem. BUT- I few my deadcat style Quad ( over 125 flights on it) equipped with a 2.4.6 FC today after upgrading to 3.6.0 from 3.5.7 . After 4 minutes of flawless flight, it seemed to just shut down. Fell ~30 feet with only a broken GPS mast!

All looked OK when I arrived at crash site, only I2C connecter was unplugged as the FC came loose from its mounting tape. I think the safety switch was solid, but not sure, as I was amazed at lack of damage, but it was lit. Back at bench I unplugged batter, connected USB and it booted fine, downloaded log, but have limited logging on this quad.

Looks like a power failure to me as log just stopped. ( Low Board VCC is 'Normal" on this FC,I checked other logs and they are all in that same range).

Reviewing the T Log I see did have a couple of dropouts of telemetry during flight as well as GPS error messages. Not normal for this flight path and range I was flying.

Have included logs and a clip of the last seconds of the on-board video.

Would you concur that this a power supply or related issue? I intend to overhaul this anyway to check all power lines etc, but may fly again as is to see if it does that again.

Thanks,
Joe

https://www.dropbox.com/sh/3a2miglyebtllmn/AAD6h9p87BM5KPVH5gzijwpqa?dl=0

13

@andypiper,

Re the compass inconsistent message if you set LOG_DISARMED = 1 and then reproduce the problem and stick the log here we can have a look. I suspect it’s something in the environment though because very little has changed since -rc12 (the actual list of commits can be seen here, everything committed on Oct 26th and 27th is what’s new for 3.6.0)

14

@mtbsteve,

I’ve talked with @wickedshell about this and apparently the underlying issue is that the GPS hardware can’t keep up (i.e. can’t deliver the position data at 5hz) with the number of constellations defined (3 or 4). So basically it’s a hardware issue and it would have happened with 3.5.7 as well but in 3.6 we are more strict in our checks. The fix is to set the GPS_GNSS_MODE to “67” which will override the GPS’s factory setting and instead enable only GPS, GLONASS and SBAS.

Can you tell me which manufacturer you bought the GPS from? We’d like to contact them and ask them to update their factory configuration.

1 Like
15

@anon67614380, @rbachtell,

Great, thanks for the feedback on using the Zubax with ChibiOS, I’ll update the notes to say “only use with ChibiOS for now”.

16

Hi Joe,

Sorry to hear about the crash although great that it survived the fall. As you say, it does appear to be a power failure because it simply stops logging at about 35m. It is actually difficult tell the difference between a power failure and a catastrophic software failure but Tridge has some evidence that the radio failed at the same time so it’s most likely a power failure.

17

@JoeBreznai the tlog shows that your flight controller lost power. The way we can tell is by looking at the RADIO packets which are generated by the ground radio. These packets contain the RSSI and noise levels of the remote radio.
What we see is this:

2018-10-29 04:28:36.04: NAV_CONTROLLER_OUTPUT {nav_roll : 5.29679250717, nav_pitch : -8.46393203735, nav_bearing : 22, target_bearing : 170, wp_dist : 0, alt_error : -0.636811494827, aspd_error : 0.0, xtrack_error : 0.0}
2018-10-29 04:28:36.04: RADIO {rssi : 77, remrssi : 75, txbuf : 100, noise : 36, remnoise : 41, rxerrors : 22, fixed : 41}
2018-10-29 04:28:37.15: RADIO {rssi : 67, remrssi : 75, txbuf : 100, noise : 42, remnoise : 41, rxerrors : 23, fixed : 41}
2018-10-29 04:28:38.18: RADIO {rssi : 63, remrssi : 75, txbuf : 100, noise : 38, remnoise : 41, rxerrors : 23, fixed : 41}
2018-10-29 04:28:39.20: RADIO {rssi : 61, remrssi : 0, txbuf : 100, noise : 38, remnoise : 0, rxerrors : 23, fixed : 41}
2018-10-29 04:28:40.23: RADIO {rssi : 60, remrssi : 0, txbuf : 100, noise : 37, remnoise : 0, rxerrors : 23, fixed : 41}
2018-10-29 04:28:41.06: RADIO {rssi : 60, remrssi : 0, txbuf : 100, noise : 35, remnoise : 0, rxerrors : 23, fixed : 41}
2018-10-29 04:28:42.07: RADIO {rssi : 60, remrssi : 0, txbuf : 100, noise : 37, remnoise : 0, rxerrors : 23, fixed : 41}

The NAV_CONTROLLER_OUTPUT is the last packet from ArduPilot. After that we only see RADIO packets, which come from your ground radio. Those packets show that the remrssi and remnoise went to a fixed value (75 and 41). That indicates that the ground radio stopped getting updated RSSI and noise information from the air radio. That is almost certainly caused by the air radio losing power.
I expect that your air radio and flight controller were on the same power supply. So what this shows is that you lost power in the aircraft suddenly.
Cheers, Tridge

18

@RickyG,

You are right! I can’t believe it but indeed, the colours are wrong on ChibiOS for Pixracer (they’re correct for ChibiOS). We will fix this in Copter-3.6.1 I think.

19

Randy,
Thanks you for looking at this. I will start with a teardown of the power side and see what I can find.
Joe

20

Tridge,
Thanks for the detailed review. When I reviewed the T Log and saw freeze’s in updates, I wondered about system power. Your review is most instructive in what to look for . Appreciate it… And you are correct; the flight controller and Telemetry radio share power from a Mauch power supply/current monitor. Everything else has it’s own BEC. Guess it’s time to hook- up a backup BEC to the Pixhawk!

Lots of flights on this bird so will check all wiring first.
Joe
PS Loved what you all did at your Outback Challenge. Amazing how you did all that.