0 = disabled for arming and disarming
1 = enabled for arming
2 = enabled for arming and disarming
1 Like
Sergey,
Is the compass failure repeatable? … and does it only happen with ChibiOS? If you put NuttX on it does the compass keep working longer?
(EDITED)
Flied a mission with nuttx version and also got compass stop feeding data.
But this time it happened after 11 minutes of flight.
Does this seem like a hardware issue? There are strange spikes all the time.
And another question is why compass still reports healthy even there is no data coming?
I’ve been trying to test it on my pixhawk on s500 frame. Blend gps, sunnysky 2216 and racerstar 28a. I had problems with oscillation on 1 esc. But Not constantly. Didn’t test much for that reason, but RTL was working good 
Hovering around didn’t gave any problems!
1 Like
Sorry but I was messing with this version and blheli suite and after a few good connections I have lose usb connection, windows not recognize the board, but guess what, It is working on Mission Planner via sik radio and seems ok.
Tried all I know with usb and windows don’t let me do nothing, changing cable, restart computer, check other board by usb, reset all parameters, check sr0 params., put blheli params. to 0… anyone have anything more?
Pixracer and MP 1.3.58 and 3.6rc10 copter
Edit:Anyway to flash the board without usb? yes, wifi module, but ftdi or so?
RC 10 runs perfectly well on my Solo.
No glitches so far.
A big thanks to all you developers!
1 Like
I still have the problem that DShot is not working on the pixhawk 2 (cube)
I have a hexa setup and connected the ESCs to Servo 9-14
With Oneshot everything is working fine but if i set Mot_pwm_type to 4, the Pixhawk hangs after booting. It takes anywhere from 10 seconds up to around a minute of uptime. (The orange Led under the cube starts blinking, everything else stops. Telemetry, Data over USB, Motors stop spinning if they were running when the software starts to hang
1 Like
I have loaded on both my Helicopters Copter 3.6.0 rc10 the ChibioOS version. On both Helis with identical FC Pixhawk 2.1 cube and LIDAR-Lite 3 Laser Rangefinder. In both Helicopters the Rangefinder is not working with ChibioOS. But loading back NuttX Copter 3.6.0 rc8,rc9,or rc10 the Laser Rangefinders are working. This is repeatable.
I must let you know I do not connect my Lasers with I2C cables.
It works perfectly on both Helis but with NuttX only.
I’m getting some strange compass behavior on chibios as well, but I can’t even arm it. Fine on nuttx.
should be mentioned in the Wiki that OSD (F4 boards) is only supported since ArduCopter V3.7 seems strange to me because all OSD parameters are available in the beta but not effective… but works great with ArduCopter V3.7-dev 
UNCONTROLLABLE SPIN AFTER ROLLOVER
Hi, i have a code built from current dev master but i suspect in this area it is same as code from rc10.
https://drive.google.com/file/d/1lzttgf3t8C2GmslaU043Ewz9LXkQpxbp/view?usp=sharing
the scenario that just happened - a model was attempted to liftoff in the alt hold mode. for reasons not relevant - operator error most likely, or hardware - it flipped over propellers on the floor. immediately after that ch8 was hit - with a function 31 to kill motors.
model ignored that, motors kept spinning wildly, it gave up to 80A at some point trying to spin them, fried motors a bit as it smelled - all this time ch8 wsa on, ignored, so i had to throw a rug on props, step on it and unplug lipo.
it does not sound as something that was supposed to happen, i would guess?
Paul !
Master is NOT release, RC releases come after a kind of feature freeze. 3.6 is in the branch Copter-3.6. Master is an interim, hardly tested working version…
dshot implementation and basic flight modes logic in rc10 and master is same. i am not saying it is a dshot issue, but i know quite well that with oneshot125 i never had motors to keep spinning in any position in any situation after kill switch 31 being hit.
but you are correct, master is not a release, so, if you choose to ignore - ignore.
I would not ignore it. Your log stops right when ch8 went high, so there isn’t any useful info in it.
Did you tested ch8 emergency motor stop before takeoff ? Is it worked before ?
after ch8 was hit it was at least minute or so of spinning, i acted quickly but it had some time to burn. odd.
yes, it definitely worked always before, no exceptions. but i did not have such a rollover in quite q while and do not really want much to re-try it…
Paul, just to overcome possible language issues (English is not my forte) did ch8 emergency stop worked on this specific copter with the exact firmware ?
yes, this same model, same code, but in normal conditions - not upside down with props on the ground. it was bouncing up and down with props revving - i was afraid it will go on fire as motors almost melted. odd stuff.
here - what i hate most - see how ch8 is hit, current then goes down and again goes up? how is it possible?
i did not notice any alteration of sound or bouncing when ch8 was hit. but graph shows current tried to go down - but merely down to 20A from 66A? Odd.
plus, the fact it pumped out 66A while laying on the ground upside down trying to rip through - also odd.
I tried to reproduce it on my tiny copter and everything worked as it should.
I held it in my hand. Put it in alt_hold. Put the throttle over mid, and the motors spooled up. I turned it over and hit the motor stop switch, and they stopped.
But, my turnover was relatively gentle and didn’t trigger a crash detection or anything. Maybe that’s a factor in your case.
I’m running master from about 2 weeks ago.
thx for trying - not sure what happened in my case. i will try to torture it a bit more later, with props off. too bad nothing is clear from that log. if it was a hardware issue i would love to know what it was…
i can only imagine that cpu ran out of limits somehow and started ignoring RCIN while giving all cycles to gyro loop? but i do not think it is how it works. plus it shows CH8 RCIN - but does not show current cut off. go figure.