chibiOS r-12 loaded on my Octo I noticed that the error sound did not give the negative tone when trying to arm before the arming switch was engaged… rock steady GPS loiter will test more…
Thanks for all the hard work guys.
chibiOS r-12 loaded on my Octo I noticed that the error sound did not give the negative tone when trying to arm before the arming switch was engaged… rock steady GPS loiter will test more…
Thanks for all the hard work guys.
Re-calibrated my compasses and re-did compass MOT. Switched to EKF3. Flew a few batteries - the most interesting one is here:
Some weirdness:
Some questions:
Other than that flying ok - so thanks all!
Buffer Full is about smart RTL. It remembers some number of points to get you back home… Regular RTL would still work.
All in all my 3.6 RC12 ChibiOS is doing good, still have few issues unresolved, i post them here to the attention of devs.
System doesn’t start magnetometers if sbus receiver is plugged in (doesn’t start I2C magnetometers as well as UAVCAN magnetometers.
System every 10 boots or so doesn’t start pwm to ESCs
Every once in a while system goes in imu1 switching magnetometers continuously.
regards,
Corrado
I’m getting this a lot, the first instance of EKF is fine on the external compass, the second instance is having all kinds of trouble:
The innovations don’t look too bad and then suddenly they stop and the EKF just switches back and forth between the compasses - almost like it’s looking for a signal but not finding it. Seems weird to me.
gps glitch means gps receiver suffers from external interference. wrap all possible sources of interference with copper foil, ground it. put a layer of foil under CF plate under the gps. wrap in foil signal wires that go to GPS or - better - use a coax or shielded cable for gps signal and power.
it gets really annoying with those gps receivers on small drones. worst source of issues is a runcam split 2 board - you can see how it jumps from 15-17 sats down to literally 8 without proper grounding as soon as split board is turned on. with shielding and grounding the best i got it was to about of 12-13 now from 18-19 sats with split not on.
battery wise i do not know what you use - my rooster in stab mode full throttle uses close to or a bit more than 100A. it sags battery crazy.
the kind i use and i think is the current best is this:
i do not advice to buy it from the original chinahobbyline site - i bought one set from there while they had a sale a month ago and still do not see anything - they sent a fake shipping number but nothing is there and do not respond to emails. racedayquads never had a problem. there is also a 1300mah 100c lipo but i prefer 1500mah ones. they are very good. i get 10min of loiter at 8A current on a rooster.
for mag interference - pls post a picture of your drone - where is the gps puck related to the motors and esc? i just made a small 3" model based on owl frame - and it is fine, max mag interference i saw was close to 70% in stab mode max current - 46A. (not sure why max A are so low on the Owl - it is a different issue), at loiter mag interference is within norm at 21% or less.
always show “gyro still setting” when reset board.
Paul, re COMPASS_LEARN = 2 (EKF Learning), the EKF can apparently learns the compass offsets in flight and it always does this learning actually. If COMPASS_LEARN is set to “2” then those offsets are saved once the vehicle is disarmed.
OlliW,
Thanks for the reminders on the issues with the Mount code. This must be the issue re mavlink messages being handled incorrectly in 3.6. I’m particularly concerned about any regressions. It sounds like this issue doesn’t actually cause problems with the physical movement of the gimbal? I guess it’s the SToRM32 gimbal we are talking about.
@Jonathan_Blumenfeld, thanks for the report on the telemetry issues on the Matek405CTR, I’ve added it to this issue so that it’s not forgotten. It’s possible that we may not fix the issue before the official copter-3.6.0 release but hopefully in a follow up point release.
@FMOliveira, txs for the report on the MP’s not showing the BATT_FS. I’ve just double checked and I think MP is working, perhaps it’s been fixed in the 8days since you made this report? … or more likely it’s only fixed in the beta version of MP.
Hi Varun,
I’m pretty sure that the Pixhackv3 does not have a CPU heater so I think the heat is most likely a hardware or environmental issue. Perhaps you could try putting 3.5.7 on the board and see if it heats up about the same amount?
It’s possible that we might be working the CPU a little harder with 3.6.0 but I if anything, especially with ChibiOS, I think 3.6.0 is more efficient - i.e. does the same amount of work with less effort.
@rickyg32, re the Solid green status LED… normally solid means the vehicle is armed and green means it has GPS lock. If you have a log we can have a peek but I’m pretty sure it really does have a GPS lock but maybe you could check by looking at MP’s HUD? If it’s reporting, “GPS: No GPS” and the LEDs are green then we definitely have a code problem.
Re the messages to the GCS, I think on MP’s Flight Data >>Messages tab there will be many messages presented. So a change vs 3.5.7 is that in 3.6.0 all causes of pre-arm failures are sent to the GCS while in 3.5.7 it would only ever send one item (once that item was resolved it would send the next failure). Because of limited space on the HUD, I suspect MP is only showing one of the messages (the latest perhaps)? It’s possible we could change the order of the messages being sent. “PreArm: Hardware safety switch” should probably not be displayed on MP’s HUD if there are other issues also present
I wasn’t able to reproduce the issue with the negative tone not playing when arming fails because the safety switch has not been pressed yet. On the MP’s Flight Data screen’s Messages tab, I see the “PreArm: Hardware safety switch” message and when I try to arm with the sticks or using MP’s Arm/Disarm button on the Actions tab, I hear the failure tone.
Maybe you could provide a log and/or more details on the steps to reproduce the problem?
Corrado,
Thanks for the reports. I’ve added the 1-in-10-boots-PWM-output issue to our 3.6 issues list. the compass-with-sbus-reciever issue could be a power issue. I wonder if you could try using NuttX to see if the problem persists?
For the imu1 switching, have you got a log somewhere?
@andypiper, could you post that log somewhere? I think we should ask Paul Riseborough to have a look at it. I know we treat the 1st and 2nd compass differently, for one of them we just try to fuse a 2D heading, for the other we try to use all 3 dimensions from the compass. That’s about as much as I know… so a log for Paul is best I think…
Re the “gyro still settling” message, perhaps we could improve the message but I think it’s underlying meaning is that the EKF is not able to get a good attitude estimate. I strongly suspect the message will go away once the accelerometers are calibrated. Maybe you could try to calibrate the accels and confirm?
Yes same with nuttx, i doubt it is power because i reproduced it with only sbus receiver and magnetometer attached to a cube 2.1, all of wich powered by a 20 amp laboratory power source.
Corrado
Corrado,
Sorry to keep asking you to do more work but could you try this with Copter-3.5.7? I’m afraid that it’s very likely this issue will need to go to @tridge and I’d like to narrow down on the possibilities before taking his time to ask him to look into this.
I guess this is a pixhawk compatible flight controller or something else?
Black cube 2.1
Yes it does it with 3.5.7 too.
I built myself a little device that waits 10 seconds before feeding sbus as a workaround and it works.