Copter-3.5-rc1 released for beta testing

ArduCopter Copter 3.5
, ,
1

Copter-3.5-rc1 has been released for beta testing and can be loaded uses the “Beta Firmwares” link the Mission Planner (and other GCSs). The changes are listed below and are also held in the ReleaseNotes.

Issues should be reported in this forum as a “New Topic”.

Warning #1: the FRAME_CLASS parameter must be set depending upon your frame type (1:Quad, 2:Hexa, 3:Octa, 4:OctaQuad, 5:Y6, 7:Tri)

Warning #2: The EKF/GPS failsafe is much less sensitive than AC3.4 which means that if flying in Loiter, PosHold, Guided, Auto, RTL and the compass goes bad, the vehicle will not automatically switching to LAND mode but instead the vehicle will flying erractically. This will be fixed in -rc2.

Copter 3.5-rc1 28-Jan-2017
Changes from 3.4.4

  1. Multicopter firmware consolidated into single binary, users must set FRAME_CLASS parameter (1:Quad, 2:Hexa, 3:Octa, 4:OctaQuad, 5:Y6, 7:Tri)

  2. PixRacer specific items:

  • board LEDs supported
  • ESC calibration start problem resolved (was sometimes not detecting high throttle from pilot)

  1. Relaxed compass calibration and compass consistency checks

  2. Sensor and Optional Hardware Improvements:

  • IMU sampling rate for MPU9250, ICM20608 IMUs to 8kHz for improved vibration resistance (Pixracer, Pixhawk2)
  • Onboard Display (http://ardupilot.org/copter/docs/common-display-onboard.html)
  • Here+ RTK GPS (UBlox M8P RTK) support
  • LightWare I2C drivers usable on Copter (thanks to in-tree drivers below)
  • MaxBotix sonar with serial interface now supported
  • Bebop optical flow (but sonar not yet operational making this feature currently impossible to use)

  1. Precision Loiter using IRLock sensor (set CH7_OPT to 39)

  2. Delivery improvements:

  1. Pozyx support for Non-GPS flight (http://ardupilot.org/copter/docs/common-pozyx.html)

  2. EKF improvements:

  • adjust for user defined sensor offset from IMU
  • improved blending of optical flow and GPS
  • EKF3 added in ride-along. Enable by setting EK3_ENABLE=1
  • improvements when using range finder as primary height reference
  1. Object Avoidance improvements (http://ardupilot.org/dev/docs/code-overview-object-avoidance.html):
  • uses mini-fence
  • accepts MAVLink distance-sensor messages
  • simple avoidance in AltHold mode
  1. Other improvements:
  1. Technical improvements (users may not see a functional change):
  • in-tree drivers lead to improved sharing of drivers with Linux boards
  • copter arming checks consolidated with other vehicles
5 Likes
3

While I agree with the consolidating binaries thing - it’s going to be confusing to a new user…and to some of the less technically inclined IMO - if they have to go track down this switch.

Mission planner will need to get rid of the choice of downloads by frame, unless it’s going to set this parameter for you upon download and flash.
I don’t use the wizard, but I’m assuming it will choose this for you if the downloader doesn’t? (or other GCS?)

Just my input.

1 Like
4

Since I can’t remember, I tracked it down. Mines defaulted to X which is good for me but maybe not for others.

FRAME_TYPE 0:Plus, 1:X, 2:V, 3:H, 4:V-Tail, 5:A-Tail, 10:Y6B

5

@rmackay9 great news!
Will you also support the Drotek RTK GPS in addition to the Here+?

6

Wonderful news, thank you very much for implementing this feature! I’m looking forward to test this.
But one question: CH7 is used to switch to Precision Loiter? Would it be it a big efford to change this, because CH7 normaly is used to trigger the camera, and this cannot be changed in Arducopter? Or am I thinking completely wrong?

Thanks,
Stefan

7

Loaded 3.5 on my P1 hex, made the frame changes and everything came up just fine. Flashed my P2 and the world turned upside down with accelerometer out of calibration, compass out and orientation upside down. AHRS is set to 0. Went back to 3.4.4 and everything is happy again.

Randy Bachtell

8

fingadar,
Precision Loiter can be another auxiliary switch like CH8_OPT, CH9_OPT, etc in case that helps. Currently there’s no way to force it so that it’s always on.

9

RandyB,

My couple of Pixhawk2 seems ok on AC3.5-rc1. Certainly some of the early PH2s shipped with the AHRS_ORIENT set incorrectly. If that’s set to 0 and the board is rebooted it should come up ok. If it’s not then I think I"ll need to see a dataflash log. Maybe it would be good to open a new thread.

10

Randy,
perfect, thank you very much. That is all with Precision Loiter that I need.

11

IMU and GPS relative position of the parameters set when to join it?

12

@rmackay9
I should have looked a bit closer before posting I guess. BRD_TYPE was set to 2. Changed to 3 for PH2, calibrated compass and everybody is happy again. If the wind here slacks a bit I will do some testing today on both PH1 and PH2

Thanks for your response
Cheers,
RB

13

Hi Lance,

There is a new parameter called Frame-Class which you have to set manually… see release info…

14

I have a 3DR Pixhawk MINI, is this board now supported in release 3.5? I tried uploading 3.4 to that board, but it always said “check BRD_TYPE: no l3gd20 found” and even manually setting the BRD_TYPE parameter couldn’t resolve this problem.

If release 3.5 has solved this error, where could I get the 3.5-rc1 beta testing version? I am using QGC on Linux and currently in QGC I can only find “Heli-APM:Copter V3.5-rc1”, which I do not think could be used for a Quadcopter and is not what we are talking about in this tread, right? Any idea how could I get “Copter-3.5-rc1” from QGC on Linux? (Sorry I do not have a windows computer for Mission Planner).

Thank you!

15

klytech, I can’t answer the question of how to get the beta releases using QGC but I’ve asked DonGagne. If you know how to upload a custom binary then you could download it directly from here: http://firmware.ap.ardupilot.org/Copter/beta/PX4/ArduCopter-v2.px4. This binary should support the 3DR PixhawkMini.

By the way, it would be best if we open up new threads for each question.

16

@RandyB,
There shouldn’t have been any need to manually change the BRD_TYPE. That should be automatically detected. I’ll add it to the list of things to investigate.

17

Zhangsir,

To set the IMU offset from the vehicle’s center of gravity in meters:

  • INS_POS1_X - IMU’s distance forward of the vehicle’s COG (i.e +ve means forward of COG, -ve means behind)
  • INS_POS1_Y - IMU’s distance right of the vehicle’s COG (i.e. +ve means right of COG, -ve means left)
  • INS_POS1_Z - IMU’s distance below the COG (i.e. +ve means below COG, -ve means above)
  • INS_POS2_X,Y,Z (same as above but for 2nd IMU)

And then it’s very similar for the GPSs:

  • GPS_POS1_X - GPS’s distance forward of vehicle’s COG (+ve = forward, -ve = behind)
  • GPS_POS1_Y - GPS’s distance right of vehicle’s COG (+ve = right, -ve = left)
  • GPS_POS1_Z - GPS’s distance below vehicle’s COG (+ve = below, -ve = above)
  • GPS_POS2_X,Y,Z (same as above but for 2nd GPS)

There are also similar parameters for optical flow and range finders.

1 Like
18

Wait,are you saying that we need to adjust GPS_POS x,y,z ?isn’t that automatic?

19

Hi rmackay9

awesome! This parameter settings really useful for traditional helicopters, and I seize the time to test the effect of the parameters.

thk you ！

zhangsir

20

@Emin_Bu Did you understand what those parameters are for? It sets the position of the GPS relative to the center of your frame. If you understood that, how do you propose we determine that automatically?