Copter-3.5.0-rc7 is now available for beta testing

re the final release, I think we’re getting very close but it really depends upon getting any remaining “critical” or not-understood issues. I think we have two of these:

Especially if they turn out to be “regressions” (i.e. they worked in AC3.4.6 but not AC3.5) then we probably need to fix them.

Hi thanks. Waiting hopefully.


I got it on 2 vehicles, quad and octo.

What is happening - it only detects GPS units (i use witespy ones) if i set types to AUTO (1) and use autoconfigure setting (1). then it detects both GPS on board as ublox 115kbit.
If i set type to 2 - preset ublox, and remove autoconfigure option - i never get GPSes coming online at all! If i set autoconfigure to 0 and type to ‘auto’ - then i get something weird - i get one GPS discovered as NMEA at 38kbit, other one as NMEA at 9600. This way it works fine.

So, the issue i have exists on the quad - octo works fine.
On the quad i have consistent issue with both rc6 and rc7 - did not try previous releases - if i set all 3 options to (1) - autoconfig, auto, auto for types - it discovers second GPS fine, prints discovery string and a hardware string. First GPS unit is this one:

So, what happens with it - it repeatedly prints ‘discovered gps ublox 115000’ message and i believe it resets GPS feed automatically, like it fails something. If i look at statistics window i can see how GPS actually tries to get sats, but then statistic drops to 0. 99 hdop, 0 sat, then blinks back to 11 sats, then drops to 0 again.

if i remove autoconfiguration option i then get this GPS unit recognized as NMEA 38kbit and it comes up online fine every restart and shows sats fine as well. So it is quite confusing why it fails.
both vehicles use same auav controller, and all gps units are from witespy, but different types. so i am quite puzzled with that, why it acts like that with the autoconfig option set and why it is unable to autodiscover correctly as ublox if autoconfig is not set?

Here is how output looks, in messages window. ‘GPS 1: detected’ keeps showing up forever.

GPS 1: detected as u-blox at 115200 baud
GPS 1: detected as u-blox at 115200 baud
GPS 1: detected as u-blox at 115200 baud
PreArm: Throttle below Failsafe
u-blox 2 HW: 00080000 SW: 2.01 (75350)
GPS 1: detected as u-blox at 115200 baud
EKF2 IMU0 tilt alignment complete
EKF2 IMU1 tilt alignment complete
GPS 2: detected as u-blox at 115200 baud
GPS 1: detected as u-blox at 115200 baud
EKF2 IMU1 initial yaw alignment complete
EKF2 IMU0 initial yaw alignment complete
Barometer calibration complete
Calibrating barometer
Initialising APM

If i set GPS_AUTO_Config to 0 - here is what i get now:
PreArm: Throttle below Failsafe
GPS 1: detected as NMEA at 38400 baud
EKF2 IMU1 tilt alignment complete
GPS 2: detected as u-blox at 115200 baud
EKF2 IMU0 tilt alignment complete
EKF2 IMU1 initial yaw alignment complete
EKF2 IMU0 initial yaw alignment complete
Barometer calibration complete
Calibrating barometer
Initialising APM

i swear before it was giving GPS2 as NMEA 9600, no clue why now it shows up as proper ublox. all this it is very odd.

Had some weird problems with rc6 today. This is the first time I have tried 3.5 in anything more than tuning flights. This is a 250 class frame with an AUAV-X2.

  • First problem was that I would keep losing OSD data on screen. (minimOSD). It didn’t happen to start with but then a few minutes into each flight the data would just disappear. I’m prepared to believe this is some kind of HW fault since it was much warmer than its been here, but I mention it because I have never seen it before and it could be FW related - either because MAVLINK data stopped, or possible because the RC7 function somehow got jammed low (which is clear screen on my minimOSD).

  • Second problem was, I armed - flew in PosHold (was going a little cautiously because of the first problem) and about a minute in my GCS piped up “Armed, waypoints received, home postiion set” even though the copter was in the air and about 100m away from me.

After that I landed and went home :slight_smile:

Any suggestions welcome


What about these:

Which probably have same nature?

Today I test a little: stab, pos hold, alt hold, RTL and them play with this mission: Commands to repeat an automatic mission (take off, 4 wp, land, delay, do jump and all work nice, the only silly issue that I saw was when take off in auto 90º to the first Wp, the copter drift a little to Wp side and then yaw to the first Wp, it´s repeated in all test, I´m not shure if occurs in older vers because I, in general, take off manually.
Roll needs more tunning yet, It has two autotune with earlier vers, I´m going to try once again with this vers or try to tune with patience (any suggestion is welcome).
I share the logs just in case they are usefull.


If you have an issue open a new topic, it is very hard to discuss and track problems here.

1 Like

Mine isn’t an important issue, really very very silly., and tune I have to do more work after ask for help; I share logs more because I thought perhaps it´s usefull for devs have more logs to check if they want to check something special, but perhaps is more for confusion, Sorry, only a bad idea. As soon as no wind I test Autotune with this vers to see what happens.
Performance is nice, thank`s for great work :slight_smile:

A while back Leonard had mentioned implementing the following in Bill’s thread about reducing instabilities, is there any chance some of this could make it into 3.5?
I am a traditional heli user and could see substantial benifets from these changes. Also with other flight control systems ive had great luck with a notch filter for eliminating instability issues with quads, so the implications reach further than just helicopters. I could see benifets for large X8 and Traditional Octa’s with large props as well.
I intend to extend the normal copter pid loop to include:

  1. separate input and D term filters
  2. a notch filter
  3. a feedforward term (input request times a parameter summed to P I and D output)

This also will enable running the pid loop in sync with the gyro read and at a different rate to the attitude angle controllers.
End Quote::::


current sensor not work fine
board pixracer. 3.4.5 work fine

i use allegro sensor + voltage divider 1/2 on current pin
voltage sensor work fine. Use custom devider

PreArm: RC Yaw not configured
PreArm: Compass not calibrated
after upgrade.

3.5.rc7.param (13.2 KB)

Okay, I will create other topic.

Hi everyone,
As @OXINARF has said above, please create new topics for new issues!

Dowload latest beta of MissionPlanner, I aksked for this in previous RC thread :slight_smile:

1 Like

I’m also having my MinimOSD stop updating with Copter3.5. But like you, I don’t know yet if it is the OSD or the flight controller. I unfortunately updated to the new minimOSD fork, that has the ‘radar’ view, and updated mavlink messages, etc. So, there were a couple of changes made at once related to the OSD.

If anyone else has noticed their minimOSD having issues, please post.

Roll autotune in pos hold works well.

1 Like

PixRacer Clone - compass issue
Made Update from 3.4.6 to 3.5.0 rc7 after winter break to 250-racer.
Because 3.5 RC1 does not support my old GPS I ordered a NEO8 GPS - everything works well with this GPS and 3.4.x

The following problems occurred after update:

  • After compass calibration and reboot - cannot arm: compasses inconsistent error
  • With only external compass active it is possible to arm. In 3.4.6 it was possible to get stable compass calibration with 2 compasses.
  • First flight with EKF-Check-2 errors and failsafe in pos-hold. - Checked equipment - made compass calibration
  • Second flight - similar problems: many EKF-Check-2, EKF-Check-0, EKF-Primary-0, EKF-Primary-1 … errors.
    Last flights in march with 3.4.6 always worked without errors.
    2017-05-26 12-48-37.bin (3.7 MB)

Had another go with rc7. No OSD issues and no home reset issues, so either rc7 fixed something or I’ll chalk it up to gremlins.


I didn’t have enought time to check osd well, only plugged one time but I noticed a strange number too, glad to listen that was solved for you,as soon as I have more time I’m going to check better and report if something looks bad. Perhaps gremlings move here :open_mouth:

Have done a few flights with rc7 on 3 different quads - a custom 8S / 800mm enduro machine (underpowered), a 6S/750mm Tarot Peeper with PH2.1/fmu-v3, and because I couldn’t get my racer working did some acro with a broken CX-20 with a Pixhawk in it. That last one was really interesting to fly, as the main pcb is broken off it’s mount, which makes the EKF work for its supper… Logs here:
Had a few little setup issues, but mostly due to APM Planner and QGC not being updated for AC3.5 yet, and a few little tweaks needed in MissionPlanner. Once I downloaded Latest MP was ok for the 3 I flew, but my racer (board type 6) won’t connect now. Suspect it’ll be fine if I do a clean firmware load on it.
Did a bunch of auto on the 8S rig, to test the waypoint yaw behaviour. I think that this is pretty much as personal preference thing, but it does look a little strange.

Same issue, I was able to isolate what happens, to some level.
Upon system restart in old 3.3 and 3.4 you would have all telemetry re-started automatically, with all streams active. Sometimes with some hiccups one would need to go into mission planner and click at ‘enable telemetry’ button in the ‘OSD’ section of additional hardware. So, this ‘OSD’ telemetry enabler does not work anymore, for sure.
I have a teensy board feeding telemetry into Taranis radio and it is very consistent now - upon restart autopilot only sends ‘heading’ telemetry data, it also sends current flight mode, and that`s it. no battery voltage, current, GPS, no nothing else.

but as soon you conenect 3dr radio to the mission planner or tower app and it communicates with the autopilot - all params get back to life and all keeps working fine after that with proper updates, even if you shut down mission planner and remove radio receiver. it works until next board restart, then it is again, heading data only.

so far no tweaking of any options seem to have any effect on this behavior, and it is very, very annoying.