Copter-3.6.0-rc6 has been released for beta testing. The changes on top of -rc5 are in the ReleaseNotes and also listed below.
- ChibiOS small enhancement and fixes:
a) KakuteF4 UART order fix
b) mRobotics bootloader and autobuild of binaries for AUAV2.1 and Pixracer
c) Mateksys F405-Wing uart reorder to better match labels on board
- Improve telemetry/GPS detection by only clearing UART when baud rate changes
We’ve still got some known issues to investigate including:
Great, solve the problem and make everyone amazing, thanks to the development team!
To confirm what I’m seeing on the PIxRacer with 3.6.0-rc6 Chibios attached is a parameter compare of the compass Device ID’s. It seems the compass’s are being misidentified and the result is they won’t calibrate. Actually the 3rd one (2nd internal) isn’t recognized at all in the MP cal routine.
An issue that that might not be related to this specific release candidate (i had it on other ones as well) but to Dshot.
The problem happens when the motor output should be 0.
When disarmed, either the startup beeps keep repeating OR the motor starts and stops continually.
When i do a motor test in mission planner (10% for 5 sec for example) sometimes it works.
This is only with BLheli-S esc’s. Replacing the esc with a BLHeli-32 esc solves the problems. (i use a mro-Pixracer (r15))
Tested (and did not work) on DYS F30A 30amp 4 in 1 BLHeli_S ESC 2-6S BB2 & T-Motor F30A FPV 30A 2-6S ESC BLHeli_S
Dshot works for me on a Betaflight-BLHeli_32-35A
I checked with a scope on the processor pin on the t-motor BLHeli-S esc and it looked block-shaped enough to me Similar to the left picture here(no input filter in the esc, which is good).
BLHeliSuite pass-trough works great on all esc’s i got and oneshot125 works too.
One small issue on BLheli-32 in BLHeliSuite (BLHeliSuite32_32302) The motor test does not work. Motor test in missionplanner does work.
In missionplanner - messages (with debug enabled, connected trough telemetry not-usb) these messages keep repeating when i do a motortest in BLHeliSuite:
ESC: MSP_SET_MOTOR 3 0
ESC: MSP_SET_MOTOR 2 0
ESC: MSP_SET_MOTOR 1 0
ESC: MSP_SET_MOTOR 0 0
ESC: MSP_SET_MOTOR 8
ESC: MSP cmd 214 len=16
ESC: MSP cmd 104 len=0
With the BLHeli-S esc’s and BLHeliSuite16714901 this is not the case (although i cant say it works the way it should because of the other issue)
As a generic request - would it be feasible to add a message during startup to issue a printout of all addresses for all detected devices on the I2C bus, in the format of device type, device name, i2c address - or similar?
If something like that already exists - pls point me on how to do it, as i am having some issues getting VL53L0X lidar to work on i2c bus right now, with no clear reason of why it is not cooperating. on arduino sketch it works fine and has correct address ‘41’ set.
I don’t think we could add the I2C address print out to the startup (it would be annoying to the vast majority of users who wouldn’t know what it meant). If you’re having issues with the VL53L0X maybe we should start a new thread for that… I think I may have one or two of these around although I can’t immediately find them.
Getting some more reports of COMPASSMOT failing on other hardware, can anyone confirm that it does work on 3.6
Hi, can you give us a run down on this? do I just install the beta 6 from MP like normal? Thanks!
I think we don’t have the ground station changes to actually take advantage of this change for the AUAV2.1 boards so you can just load the regular beta firmware. If you really want to try this new binary, then it can be found in this directory and then the ground station’s “Load Custom Firmware” feature could be used to upload it.
What is slightly confusing is that we have multiple binaries available. They are described on this new wiki page but in short, you’d want to load the *.apj file. It’s theoretically possible to upload the *_with_bl.hex file (this file contains a new bootloader) but I can’t actually tell you how to do this because I’ve never done it on a pixhawk board.
The only advantage of this AUAV2.1 specific firmware is that the BRD_TYPE will definitely be set correctly for this board.
I’m a little confused, may someone can explain for what Cube Black is in the firmware download section and what the difference is between PH2.1 and Cube Black. Which ChibiOS file for PH2.1
i have loaded 3.6rc6 on auav from standard MP app screen and it works fine with no issues whatsoever.
I think it’s best to mostly ignore the new board-specific builds because there is no difference in functionality between them for now at least. I think we are creating them because in the longer term, we’d like to be more sure of what board is being used so we can better detect hardware issues. That’s going to probably require one or both of these:
- ground station changes to allow users to specifically say which board they are using
- the manufacturers of the boards to load specific bootloaders on the board so they can be distinguished.
Instructions for loading the ChibiOS based firmware onto a Pixhawk or Cube is here.
thanks for the explaination. Just want to be sure not using the wrong file for the Pixhawk 2.1 to be sure about the not functioning relay. I switched to 3.5.7 - 3.6. Nuttx and back to chibios. With all versions relay working exept chibios.
Loaded 3.6rc6 through Mission Planner onto a Pixhawk Cube 2.1 on a X Octocopter frame. Having trouble with my motor order I have the motors as follows then the actual motor that is spinning with motor test.
Motor Number Actual motor that spins
A 1 A
B 3 F
C 8 D
D 4 G
E 2 B
F 6 C
G 7 E
H 5 H
Somehow I am out of sync? Had this Cube running on a quad and just moved it to a octocopter. To get the octocopter firmware to install I had to install plane and then the firmware. Using top right motor as A then in a clockwise direction. The numbers are the port numbers on the Pixhawk. Maybe someone can spot what I’m doing wrong.
This is a bit odd about how the Relay doesn’t work. I’ve just tested it on my Cube using the ChibiOS firmware (the one ending in .apj) from this directory and it works a-ok. You’re triggering the relay using an auxiliary switch?
The motor order for the X8 is on this page. For whatever reason it looks like the left two motor (2 and 3) have a different order on the QuadX vs the X8.
Re the pixracer compass issue, we’ve replicated the problem and a fix is coming in -rc6 within the next week. Thanks very much for the report!
Great! Standing by to test it out.
yes its odd for me too because with exactly the same settings the relay works with Nuttx. It’s a PH 2.1 from Hex. I use RC12 Switch for Relay
3.6.0-RC3_Chibios_4S_02_Filt-34-17-10.param (14.4 KB)
I thought my setup nothing special, Quad+, Oneshot125 on Aux 1-4
In MP the Status of ch12in shows 1000 - 2000
Just did a test with CH10_OPT34 and what do you think? It works
Also CH11 works but with CH12 ???
Sorry for making trouble and thanks for your testing. It would be great if you could test CH12_OPT34 if it works or not.
OK, I’ve reproduced the issue! It appears to be an input processing issue on Ch12 on ChibiOS on Pixhawk. Other auxiliary functions also don’t work when connected to channel 12. I’ll talk with @tridge and the other ChibiOS experts (as a side note there are a bunch of new developers that have appeared with the intro of ChibiOS)