We’ve just released Copter-3.6.0-rc12 for beta testing. This version can be downloaded using MP and QGC using the “beta firmware” links.
The changes are in the ReleaseNotes and also copied below:
Bug Fixes:
a) DSHot ESC driver race condition fix (could result in board freezing up)
b) EKF fix to rounding off home altitude (could result in slightly inaccurate home altitude)
c) Pixracer safety switch fix (BRD_SAFETYOPTION parameter was handled incorrectly)
The most important fix is the first one, the DShot race condition. If your vehicle is using DShot we highly recommend upgrading to this version before you fly.
We believe that we are very close to the final official release so we greatly appreciate any willing beta testers to give it a try and report back especially in case of problems. Thanks again for all your help in getting us this far!
Probable bug on matek f405 std: after several attempts to install a m8n gps I confirm that only the magnetometer works … no GPS detected, tested 3 gps on all the serial available. can someone help me?
Today tried rc12, first i was with ChibiOS and on my quad i got some serious position drift on high wind like 5-6 meters from desired position. Then i was back to Nuttx and position hold was good.I will upload logs so if anyone wanna get on this issue.
On chbios, i still have it with this build and with dev master. I have ch9 set with a function for simple mode. It always comes active after arming, even with switch off. Turning switch into on and back to off still keeps easy mode on. Removed channel 9 from radio, armed, easy mode on. Not sure what it is.
If i define supersimple mode as well - then somehow after avsequence easy on, supersomple on, then easy on again and then ch9 off to set easy off - it works. If i just do easy on and back to off - it stays on.
Re the matek f405, I guess you’ve seen the instructions at the bottom of this page showing how to connect a GPS? Matek actually sells their own GPS now, are you using that one or something else?
I had a look at the logs. There’s a moment in poshold where I think the roll input was interpreted as the pilot wanting to control the vehicle. I’m not sure but it looks to me like RC1_TRIM (Roll) is set to 1500 and RC1_DZ is only 20 but the receiver is regularly producing values of 1510 to 1530. At the beginning of the flight RC1 (roll) is right at 1500 but in the second part of the log (perhaps after a disarm/arm?) it’s higher. Maybe the transmitter trim switch was moved.
Otherwise the ChibiOS log looks pretty good. About the same as NuttX but it’s slightly better in some ways. The GPS accuracy is a little better (this is just the GPS condition and doesn’t change based on whether ChibiOS or NuttX is used). the loop timing is definitely better under ChibiOS with 0 missed loops and a much more regular loop time. Mostly pilot’s can’t see this improvement too much in flight.
I’m trying to recreate the issue but having some troubles. Sorry if I’ve asked this before but could you set LOG_DISARMED = 1, reproduce the issue and then download and post the dataflash log?
Can I also ask what receiver and flight controller are you using?
EDIT: By the way, I thought I saw the issue once while trying to reproduce it but I’m unsure if it was my imagination or not because I can’t seem to reproduce it again. If you’ve got any advice on steps to reproduce it that would also be great.
Hi rmackay9, thank you for spending your time looking logs… I will look at trims today and re calibrate everything. What are you suggesting is to make Deadzone to 30 or 40? And i forgot to ask can u see in logs is my PIDs tuned good? I mean can that have effect on holding good position on windy conditions? And after you see both logs did you preffer to switch back to ChibiOS?
Flew four 4s batteries on my 180mm miniquad today - Pixracer, Nuttx 3.6.0-rc12
With my barometer well taped and foamed and with PSC_ACCZ_FILT set to 40 and INS_ACCEL_FILTER set to 40 all the motor pulsing and altitude issues appear gone, Thanks @Paul_Atkin1
There is a spurious debug message that I see for the last few rc’s - SUCCESS: executed CMD 179, or something like that
I get various errors in autolog analysis that I don’t get with previous GA firmwares:
– Found NaN in CTUN.DSAlt
– ‘THR_MIN’ not found
– GPS = UNKNOWN - join() takes exactly one argument (2 given)
I am occasionally losing telemetry on my OSD, I’ve had this before with other beta firmwares in the past, so it could be hardware or it could be some timing thing
RTF has a couple of times refused to descend - it gets to the right lat/long but then just sits there. I have some TBE, so I guess it could be related to that.
My VIBEX is peaking above 30. I have mounted the FC on the rubber matek standoffs, but still high - presumably this is too high?
Yeah, thanks for this… I forgot I had trouble w/ that setting being low in the past. I got it to work on my latest microcopter, but maybe it’s not the best advice to start at 10hz like I had posted in my microarducopter thread… I just edited the post where I mention the filter settings to say 10 might not work for everyone.
I’m trying to understand why, and I guess it’s that for some very powerful copters, the motors deliver power so quickly that it’s overshot the altitude by the time that 10th of a second passes.
I’ve had a chance to analyze my logs now and they are not quite what I was expecting. Logs here:
The MAG innovations are pretty reasonable (didn’t expect that).
The GPS innovations are horrible - and yet the GPS data doesn’t seem that bad, HDOP is low and stays low. I’m getting lots of GPS glitch errors and yet I’m failing to see what is causing this other than the EKF thinks its bad.
The Baro innovations are horrible - my baro is taped and foamed, not sure what else I can do.
I agree on both gps and baro innovations, i saw that too. No real explanation for that but with some tuning it works.
Gps glitch i am quite sure is not code. It is an interference to gps signal cable from other components. Try to re-solder gps using shielded cable or use copper tape to wrap cables - make sure to ground it. I got now no gps glitch at all from initially not been able to lock into a single satellite.
Also i switched to ekf3.
The NaN in CTUN>DSAlt is a known issue with the log analyser. It’s on the to-do list to fix but doesn’t affect flight (it only runs on the ground station).
It might be good to go back to 3.5.7 to help separate what issues are specific to 3.6.0 and which are not. I suspect that most of these issues are actually setup issues. separating them helps keep the 3.6.0 testing from getting weighed down with regular setup support calls.
I found what was wrong with RC1 (roll),opened transmitter and found cables was touching gimbal and probably blocking and moving it. Found also cat hair Now is fine, and i recalibrate transmitter in Mission Planner. I will test fly today to see how is going now. rmackay9 thanks for your help.
Thanks for the log. The good news is that the attitude control looks really good so hat’s off for your tuning efforts.
Vibe.X is a little high between 20m/s/s to 30m/s/s. This is in the acceptable range but I mention it because the X axis is significantly higher than Y and Z.
The compasses don’t very good. It seems like the first compass (external one?) has been disabled (which is OK) but it’s orientation also seems incorrect. It’s set to “4”… I’m not sure what it should be but Copter-3.6.0-rc12’s compass calibration will actually fix the orientation for you if it can.
The GPA.HAcc and VAcc (GPS reported horizontal and vertical accuracies) improve after about 30 seconds… this is really the GPS just needing a bit more time before takeoff I think.
Now is fine, and i recalibrate transmitter in Mission Planner. I will test fly today to see how is going now. rmackay9 thanks for your help.