Copter-3.6.0-rc3/-rc4 is available for beta testing

ArduCopter Copter 3.6
1

Copter-3.6.0-rc3/-rc4 is now available for beta testing and can be downloading using the Mission Planner’s (and perhaps other GCS’s) Beta Firmwares link.

The changes are listed in the Release Notes and also copied below:

  1. ChibiOS:
    a) airbotf4, matekF305, matekF405-wing, omnibusf4pro, mini-pix, omnibusf7v2, revo-mini, sparky2 binaries built on firmware.ardupilot.org
    b) STM32F7 support including the CUAV v5 Autopilot and the PixHawk 4 (aka fmuv5)
    c) fixed dataflash logfile dates
    d) bootloader included in firmware for easier uploading
    e) additional UART added to fmuv4 and fmuv5 (STM32 F7 boards)
    f) ChibiOS version written to dataflash log files
  2. TradHeli
    a) fix collective jump on rotor shutdown in AltHold and Loiter
    b) fix interlock pre-arm check
  3. Follow uses relative altitudes (FOLL_ALT_TYPE param allows specifying relative or absolute alts)
  4. Auxiliary switch de-bounced to avoid false positives
  5. Bug fixes and minor enhancements:
    a) ESC calibration fix
    b) ESC_TELEMETRY messages sent to ground station
    c) ESC Telemetry current scaling fix (added in -rc4)
    d) LED pre-arm GPS colour fix if glitch occurs (added in -rc4)
  6. Build-in OSD improvements including home direction fix, altitude fix (added in -rc4)

This was a “rebase on master” meaning we brought in all the changes that have been made in the last month (not just critical changes) so it really is the latest code available even to the developers. This was required because of all the changes in the ChibiOS area in particular. Any future release candidates we do will be much smaller updates than this one.

All testing is greatly appreciated and my main focus over the next week is addressing any issues that crop up so that we can get Copter-3.6 out the door so you can expect faster replies from now on.

Thanks again for helping us get Copter-3.6 ready for the general public!

2 Likes
3

This is fmuv5 - also supports the Pixhawk 4

2 Likes
4

I’m unable to upload to a revo-mini from mission planner, the board shows up as a PX4FLOW briefly then as a STMicroelectronics Virtual COM Port, mission planner connects and works as normal but cant detect the board type for flashing. It asks if its a APM or a PX4 then gets most of the way through reading the HEX before saying connection lost.

I had the same trouble before and used:
./waf configure --board revo-mini
./waf copter --upload
but not ideal to have to compile every time.

not to sure whats going on, I followed the instructions on the wiki and flashed the boot loader. Possibly it has something to do with using the with or without bl hex version although i have tried both? or I have made some other mistake somewhere.

Thanks

1 Like
5

Will D-Shot support come to the 8 regular servo channels instead of just the AUX channels? What is the biggest hurdle of getting this supported?

6

Pete,

Re uploading to the revo-mini, I don’t personally have one of these boards (or even anything similar) so I’ve asked if anyone on the ArduPilot/ChibiOS gitter channel can provide advice.

We have some advice on the developer porting wiki page and the firmware is now being built automatically and placed in this directory but I’m afraid that bring me to the end of my knowledge on this so hopefully someone else can pitch in.

7

Flew 6 flights of 3.6.0 rc3 ChibiOS, on al Quad with a Pixhawk2.4.8. All OK in Stab, Althold, Loiter, Circle, Poshold. Mission, RTL, and smart RTL. Auto-tune works Ok as well, but I didn’t hear the beep upon completion as in earlier non-Chibios versions. Did not test Nuttx version yet.

Poly Fence (All) now works as does Circle and Altitude Fence functions.
Log download has date and time correctly.

Still a Problem with Compass CAL: “Onboard Calibration using RC Controller stick gestures”

Under ChibiOS 3.6.0 rc-3, rc-2 and rc-1, there are no “Beeps” from the buzzer while doing, or at completion. Tested on Quad Pixracer only, under Chibios software.

Compass Cal triggered via MP telemetry works OK with bars moving and saving results.

However; using RC Stick Commands there are only messages on HUD and " Messages" Tab about Cal starting. At end you get a message only in the “Messages” Tab, that it is complete and the need to reboot.

Using Stick Command it seems to work OK, just no beeps to let you know where you are without a MP screen to look at.

So far looking good. Bit windy today but no problems so far.

Thanks for all the effort put forth in this release.
Joe

@rmackay9
ADDITIONAL INFO ON MISSING BEEPS In CHIBIOS BUILD: Flew 6 flights of rc3 in mRo Pixracer quad running ChibiOS version of 3.6.0-rc3 today. Noticed that when the arm button is pushed, the confirming beep is not sounded. Likewise at the end of Auto-tune , no beep from copter. NuttX version or rc3 on Pixracer beeps as in 3.5.in both cases. Also Low Battery warning Beeps under ChibiOS sounded softer than under NuttX. ( Maybe just me or a different frequency of beep ). No other issues found.
Thanks again.
Joe

2 Likes
8

I just updated the Pixhack nano + FBL unit firmware of the T-rex 500Pro DFC to 3.6rc3. The ground test is normal. I will test it according to the weather tomorrow, and then report back the test results.

Cheers, thanks to the developer’s contribution!

1 Like
9

pixhawk chibios version build failed， details as below

[512/515] Linking build/fmuv3/bin/arducopter
[513/515] Generating bin/arducopter.bin
[514/515] Generating bin/arducopter.apj
[515/515] Generating bin/arducopter.hex
Traceback (most recent call last):
File “/home/ubuntu/ArduCopter/ardupilot/Tools/scripts/make_intel_hex.py”, line 4, in
import intelhex
ImportError: No module named intelhex

10

You are missing the intelhex python module.

‘sudo pip2 install intelhex’ will fix it.

11

thanks for your reply. :slight_smile:

12

Yssaril,

Re D-Shot on the main outputs (of a pixhawk or compatible board), there’s an issue here on the to-do list for it so it hasn’t been forgotten. Still, I don’t know when/if it will be implemented but I think it’s unlikely to be done for Copter-3.6. I think if you like or comment on that issue then you’ll be notified when it’s completed.

13

@liang-tang,

re that build error, I think a change has since gone into master that allows the build to complete without having that intelhex module installed. I’ll pull this into the Copter-3.6 branch so the error goes away.

14

JoeBreznai,

Thanks for the report on the ChibiOS firmware missing the beeps during compass calibration. I’ve added it to this issue so we won’t forget it.

15

If it is the first time that you flash the revomini with arducopter you have to put the board in DFU mode, see here, then you have two option:

  1. flash bootloader using this instruction
  2. flash this with inav-configurator
1 Like
16

Thanks, I have flashed boot loader using option 1 but still no luck, will try option 2

18

ChibiOS builds seems not to like my mRo x2.1 rev2 rc -1 rc-2 rc-3 same issue with jerky gps.

I made a custom build of 3.6 hex and it flys fine gps lock is good. Anyone have a v2.1 with jerky z in GPS?
why would the nuttx one be ok?

Frame: HEXA
PX4v3 00350024 3236510D 36363331
PX4: 1e7ed30b NuttX: 1472b16c
ArduCopter V3.6-dev (802f6a4a)

Wondering is the ChibiOS install via MP is loading the wrong version to my mRo.
PX4 uses the Board ID to download a “precompiled” firmware specific for your board (ie. FMUV2/PixHawk1, PixRacer, PixHawk Mini, X2.1, etc).

ArduPilot on the other hand just uses the BoardID via Mission Planner to download the right generation of code (PX4v2 (PixHawk1 Rev2 STM32 Chip with limited memory Issue), PX4v3 (PixHawk 1 Rev3 STM32 chip, PixHawk Mini, etc) or PX4v4 (PixRacer, etc). https://github.com/mRoboticsIO/Hardware/wiki/X2.1

1 Like
20

After the collective pitch of 3.6rc2 is abnormal, and in the test of returning the firmware of 3.5.5, the problem of jitter in the take-off rolling direction occurred. Finally, it was confirmed that the steering gear of No. 2 was faulty, and the servo was returned. After the factory repair, re-installed on the T-Rex500DFC, checked the status of all the mechanical and basic electronic equipment on the ground, confirmed that my helicopter did not have problems other than flight control, updated the firmware to the latest released heli last night. 3.6rc3, and directly used in the 3.6rc1 firmware, has been tested to fly almost perfect parameters.

This morning, in my T-Rex500DFC RC helicopter, CUAV Pixhack nano（PX4v4） flight control, CUAV mini M
8n GPS, and Vbar FBL Unit combination test, tested two batteries, three sorts of test flights, 3.6rc3 performed very well. Including Acro mode, VBar FBL Unit’s manual flight performance, stability mode, Loiter mode, Poshold mode, winding mode, automatic mode (high-speed curve waypoint), RTL mode, Land mode, etc., are all very normal. Everything looks good.

This is the first test video to take off:

There is a small problem. It has also appeared in the previous 3.6 dev. During the download of the log, the MP ground station will report the EKF error, and once the logs file is downloaded, the error report will stop.

QQ%E6%88%AA%E5%9B%BE20180704091816
QQ截图20180704091816.jpg1388×664 129 KB

QQ%E6%88%AA%E5%9B%BE20180704092959
QQ截图20180704092959.jpg1387×972 184 KB

The log file with the test flight is attached:

Thanks to the development team’s work, the firmware development of the traditional RC helicopter can be continuously updated, and the performance is getting better and better. I look forward to the launch of the 3.6 official version.

Cheers

Zhangpengsir

1 Like
21

zhangpeng,

Thanks very much for the detailed feedback and I really love seeing these videos!

The EKF error during the dataflash download is because the main loop is running slowly (during the download). I’ll talk to the other developers in the weekly meeting to see if we have any ideas about this.

22

I defined a new ChibiOS board without line ROMFS io_firmware.bin Tools/IO_Firmware/fmuv2_IO.bin(because there is no io mcu on my board)
, and got some error when build. But when i added bootloader file to Tools/bootloaders, compiled successfully. So, bootloader file is necessary?

Build failed
Traceback (most recent call last):
File “/home/ubuntu/ArduCopter/ardupilot/modules/waf/waflib/Runner.py”, line 270, in task_status
return tsk.runnable_status()
File “/home/ubuntu/ArduCopter/ardupilot/modules/waf/waflib/Task.py”, line 653, in runnable_status
new_sig = self.signature()
File “Tools/ardupilotwaf/ap_persistent.py”, line 32, in _signature
s = _original_signature(self)
File “/home/ubuntu/ArduCopter/ardupilot/modules/waf/waflib/Task.py”, line 626, in signature
self.sig_explicit_deps()
File “/home/ubuntu/ArduCopter/ardupilot/modules/waf/waflib/Task.py”, line 714, in sig_explicit_deps
upd(x.get_bld_sig())
File “/home/ubuntu/ArduCopter/ardupilot/modules/waf/waflib/Node.py”, line 922, in get_bld_sig
ret = cache[self] = self.h_file()
File “/home/ubuntu/ArduCopter/ardupilot/modules/waf/waflib/Node.py”, line 902, in h_file
return Utils.h_file(self.abspath())
File “/home/ubuntu/ArduCopter/ardupilot/modules/waf/waflib/Utils.py”, line 251, in h_file
f = open(fname, ‘rb’)
IOError: [Errno 2] No such file or directory: ‘/home/ubuntu/ArduCopter/ardupilot/build/f427-custom/ap_romfs_embedded.h’