Copter-4.2.3-rc1/rc2 has been released for beta testing and should appear in the ground stations (MP, QGC) within the next few hours. The changes vs 4.2.2 are in the Release Notes and copied below.
New autopilot support
a) CubeOrange+
b) Foxeer Reaper F745
c) MFE PixSurveyA1
d) Pixhawk6C and Pixhawk6X
Bug Fixes and minor enhancements
a) Battery monitor health check fixed to check all enabled monitors
b) ICE Lutan EFI update serial flood fixed
c) ICM42xxx IMU filter settings improved and allow for faster sample rates
d) INA2xx batteries may init after startup
e) KakuteH7 OSD parameter menu enabled
f) Lua script support to set desired speed in Auto mode
g) Notch filter ordering bug on loss of RPM source fixed
h) Payload Place mission command obeys specified altitude type (was always terrain alt)
i) PreArm check that MOT_PWM_MIN/MAX are non-zero
j) PreArm check of Rangefinder pin conflict and servo outputs
k) SCurve logs debug if internal error occurs
l) WSL2 upload fixed (developer issue only)
m) BlueRobotics Navigator autopilot filesystem fix
As per usual all testing and feedback is greatly appreciated!
P.S. -rc2 was released shortly after -rc1 because we missed including the final fix for the BlueRobotics Navigator autopilot
Am I right that the messages I encounter with my PixRacer boards (Internal errors 0x1000000 l:169) have something with the “ICM42xxx IMU filter settings improved and allow for faster sample rates” bugfix?
EDIT: if yes, then 4.2.3-rc1 still results in the above-mentioned internal errors (when all sampling runs on 8kHz).
No - this is an imu reset on one of the older Invensense chips, it is unaffected by that change. You are unlikely to be successful on an F427 running gyros at 8k. I was never able to push my imus beyond 1khz on a Pixracer - you simply need more processing power.
This is kinda strange. It sort of flies at 8k/8k, especially if the ICM module is disabled, and the internal errors do not appear anymore if the frequencies are 8k/4k by INS_GYRO_RATE=2.
By the way, the fact that they switch to 8k for the first of these frequencies seems to be unrelated to user configuration (or am I wrong?). May that be a bug on itself?
The first number simply refers to the sample rate, the second number is the backend rate (i.e. gyro rate). It will fly, it’s just the lack of CPU means it won’t be able to (for instance) track the notch frequency correctly.
I mean, where is the sample rate configured? I tried to compare a very old config and the latest one, and could not find anything related except for INS_FAST_SAMPLE, which was 1 out of the box. Shall that not mean that it engages 8kHz anyway even in the default configuration pre-loaded for PixRacer?
A few issues I’ve encountered prior to attempting first flight:
(Using X4 configuration, Pixhawk6X GS running on Linux)
Firmware upgrade not possible in regular fashion - need to use .apj file
MP (1.3.77) list of firmware files is updated and beta version showing. However, despite regular connection working via USB, when trying to upload firmware a connection error -serial port- is displayed. (I do know can’t have live connection whilst doing firmware upload)
QGC (daily) getting stuck on “downloading list of available firmware”
However, .apj file upload works fine, at least on QGC - haven’t tried MP.
Next issue:
In overview in QGC it shows a question mark under accelerometer. Does this mean a sensor has not been recognised ?
(Sensors ICM-42688-P & ICM-42670-P appear to be missing)
I flew 2 batteries on two different quads with no issues what so ever, did a quick auto mission, loiter, guided and rtl. I saw no issues other than the yaw behavior seemed a bit off in auto and guided compared to last time I flew. please see attached logs.
FC: Pixracer R15
Firmware: 4.2.3-rc1
Frame:250mm on 6" props
ESC: SucceX 50A 2-6s lateset version of blheli_32 (39.2 I think)
BAT:3S
Power monitor: MRO ACSP7
Log 1 is a little hover flight to get some data for the notch filters Log 2 is some loiter, guided and just general flying around Log 3 is a little auto mission and a RTL
One thing maybe its me but it seems guided and auto yaw behavior has changed but again that could be me here is a log with some guided and what not on same quad running 4.2.2.
I am sure the yaw behavior was something that I failed to set right or am miss remembering how it was in 4.2.2. Either way dang you guys have made it so fun to test stuff now. I have about 5 quads that I will have to be setting up various notch filters on from ESC telem, to throttle based so I look forward to helping clarify some of the confusing stuff and making it easier for not so advanced users to use features. @Leonardthall had requested a user do a mission to test a bug and I cannot find the post but would be more than happy to test it out if he could refresh my memory on what it what it was something about auto mission and rtl with the quad climbing but I cannot for the life of me find it. I have logs from another 6" quad that I did identical mission and flight on but it was pretty non-eventful so I didn’t post them but I could.
Unless you can reproduce the same problem it isn’t worth spending any time on it. I think Randy has already found and fixed this problem so I hope it is all done.
Your yaw performance looks pretty tight in the log so I am not sure what you are describing when you say it looked a bit off.
Its the behavior pointing the nose into the next guided point or way point in auto. In the pre 4.2.3-rc1 the quad would point its nose toward thew next way point (at least I thought it did) but in this is seems to not and I did not change any params just uploaded 4.2.3.
@Leonardthall
I was just asking about this on edge tx discord as on all my models (with this radio) I have triple checked why this is as I do not have any trim or anything programmed into the yaw on my radio. I did just get new AG01 gimbals and have been fighting this since then.
I assume you calibrated your radio after changing the gimbals (both on the radio and then in the autopilot). A stupid question maybe, but better to ask a stupid question than miss a simple fix.
If you have calibrated your radio (I mean in mission planner on the autopilot) and you are getting this problem, then the centre stick position or reading must be changing. Maybe something loose in the physical gimbal?
Yes I have recalibrated within edgetx and arducopter which has not solved this issue. I have sent a request to the manufacture to correct the defect as I have 2 of these radios identical to each other and the other has not got any issues. This maybe a dumb question but can I just trim this out for the time being (or just use the other radio), I cannot remember but seems like using trim may cause other issues. I may have dreamed that up. This now dawns on me that this is 100% the reason why I had such a hard time autotuning.
If you simply recalibrate the RC on the autopilot it should set the trim value for you. However if you have done this already it must mean your trim is changing over time. So I would expect everything to work for a while then see the same problem again.
yeah seems like these hall effect sensors have a bit of drift on at least this one! which happens so no biggie will see if I can get it replaced and will go to my back up radio. But now I suspect that when I did some fiddling in edgetx companion and reloaded my profiles I needed to recalibrate again. Thanks for the help in identifying the problem and I will read that thread and see if I can fly a mission like that user did.
