Copter-4.2.0-beta2 has been released fro beta testing and can be installed using MP or QGC’s beta firmwares link or can be downloaded directly from firmware.ardupilot.org.
Changes vs 4.2.0-beta1 are in the ReleaseNotes and copied below
Auto and Guided mode changes
a) Delay removed when waypoints are very close together
b) Pause and continue support (GCS changes are still pending)
c) Takeoff and landing use position controller with slower reposition speed (also affects RTL, Land modes)
d) Waypoint navigation will make use of maximum waypoint radius to maximize speed through corners
Follow mode supports FOLLOW_TARGET message (sent by QGC ground station)
Bug fixes
a) Arming checks ignore SERVOx_MIN, MAX if setup as GPIO pin
b) BeastH7v2 BMI270 baro support
c) DShot prescaler fix (ESCs were not initialising correctly)
d) EKF3 variance constraint fix used to prevent “ill-conditioning”
e) POWR log message MCU voltage fix (min and max voltage were swapped)
f) SPRacingH7 firmware install fix
In particular I’m wondering how people feel about the new slower repositioning speed in Land mode and during the final descent in RTL.
I am afraid I have a regression regarding MinimOSD working through telemetry port. It works with 4.1.5 (including firmware downgrading) but does not work with 4.2.0-beta2 (having a “no input data” screen). Unfortunately, I did not test it with 4.2.0-beta1, but the development version of 4.2.0 that was there before installing 4.2.0-beta2 worked the same.
The flight controller is PixRacer R15, the second telemetry port is used.
For some reason I suspect the problem might be somewhere in the logging/threading facility, due to few “logging failed” and “logging thread stuck” messages observed when switching back to 4.1.5. However, a clean run of 4.2.0-beta2 does not tell any problems in the logs.
I am aware that the 4.2.x series has the new bit 20 for video stabilization, and this bit is set to 1 for me. However, the same thing happens when this bit is unset.
Could you maybe point me to a way to find out what is wrong? It is not very comfortable to fly without an OSD
I haven’t had a chance to check out the 4.2 betas yet - got sidetracked doing some photo survey missions.
I’m anxious however, to check out the optical flow calibration.
Randy - you mention “new slower repositioning speed” - which speed is that exactly? It doesn’t ring a bell. My copters all pretty much stay centered over the HOME point during landing and final-landing phases.
Thanks for testing 4.2 and reporting back. Any chance you could provide an onboard log? Ideally one for the working 4.1 and the not-working 4.2.
The MinimOSD uses mavlink so my first guess is that the SERIALx_BAUD or SERIALx_PROTOCOL (where “x” is the serial/telemetry port connected to the MinimOSD) has changed for some reason.
Update: as highlighted on this other thread, the issue must be the change to when AP starts using MAVLink2. Could you try setting SERIALx_PROTOCOL = 1 for the serial port connected to the MinimOSD?
The slower repositioning is during the final phase of RTL where the pilot can move the vehicle around a bit with the roll and pitch sticks. The maximum speed is much lower now.
We hope everyone find that it is fast enough and we think the lower speed means the vehicle is less likely to still be moving when it touches down which should reduce the (rare) instances of a vehicle flipping after landing.
Regarding optical flow calibration, what kind of test flights does the firmware expect? It feels that it wants a lot of aggressive moves: in an indoor test on a free space of 3x3 meters I managed to get X to 100% but Y only to maybe 70% before the calibration times out, and that only by risking to break into surroundings.
And maybe a question #2: will the hard-coded timeout of 120 seconds be eventually moved to the parameters?
For the optical flow inflight calibration it requires roll and pitch movements of 20deg/sec and the yaw/heading should not rotate by more than 20deg/sec… Also it is best to do it with a GPS attached and from a high altitude (but still within the range of the lidar).
We can very easily make the timeout longer. it’s 2min at the moment but I could increase it to 3 or 4 perhaps. In my tests it was all done in 15 seconds so I suspect it’s taking so long on your vehicle because it’s not getting good sensor values or they aren’t adding up to a good result.
I have that 3901 Matek optflow chip, whose lidar part works only until 2 meters, so flying at the recommended 10+ meters is unfortunately not an option
My today’s outdoor test did end up reaching 100% in both axes, from the third attempt. However, the resulting fits failed, particularly with a negative scalarx value (although I did test beforehands that angle changes are correlated in the IMUs and in the optical flow). May this be related to the fact that 3901 apparently wants flow scaler values of order -800?
Here is the log of the test flight. Maybe it may assist in improving the calibration procedure.
Thanks very much for giving it a try and providing the log.
I just don’t think the inflight method is going to work from such a low altitude. It really is an important requirement that the vehicle be at a higher altitude. The wiki states 10m, perhaps 5m is ok but 0.6m is just too low).
Maybe you could try simply holding the vehicle at 1.5m off the ground and rotating it by hand in roll and pitch to see if that works any better. You could disable the GPS because you won’t be moving it horizontally.
By the way, the lidar’s reported distances are at best 0.8m and are often dropping to 0 so perhaps the lidar isn’t working well outdoors. This is sadly not surprising because we’ve seen these short-range STM lidars used on other flow sensors (including hereflow) and determined that they’re pretty much useless. I think it would be best to attach a separate lidar with a better range.
I guess these drops to 0 were basically caused by high attitude angles and shortest distances to the ground well exceeding 2 meters. Or by the ground being covered in snow
Well, I missed the fact that optical flow calibration can be done without arming. That’s great! Maybe it needs to be mentioned explicitly in the docs. However, doing pitching and rolling by hand seems to provide only little data in my indoor attempts (like at most 20% in each of the axes, gathered in first few seconds then not increasing for the next two minutes). Actual flying seems to collect data better.
In any case, I decided to do the manual fit, as in good old times, which resulted in scaler values of -800 in both axes. Tomorrow I will try to check loitering outdoors, maybe it already works
This actually caught me once too, I think the parameters will appear if you reboot the autopilot. I think maybe what has happened is that individual backends can now create their own parameters (before they all had to be shared) so this can mean that the parameters don’t appear until a reboot which causes the driver to be instantiated.
