[v1.14 Release Candidate] - Flight testing & Flight Issues (logs) #21358

mrpollo · 2023-03-22T16:22:52Z

❗ About

💡 For the upcoming v1.14 release, we are asking the Community for flight tests. This issue will be used for keeping track of all the tests from the Community.

If you're unsure about upgrading, please read the preliminary release notes on the PX4 docs. Pay close attention to the Upgrade Guide before deciding if v1.14 is right for you.

v1.14 Release Notes

Pending Issues

[x ] Cube Orange Plus target for beta not available in S3 bucket: [v1.14 Release Candidate] - Flight testing & Flight Issues (logs) #21358 (comment)

❓ Why we need flight testing

🌏 Thousands of people around the world depend on the stable release of PX4.
🖐️ Before every major release, as much testing as possible is needed to ensure that our release actually works!
😯 Simply said, more testing = better release
🤗 We would like to encourage every community member to join us in improving PX4!

🤷 How you can help with flight testing

😱 Even if you have never contributed a flight testing report, fear not! Please follow the steps below for the details of how you can contribute flight testing.

Select a category from the "flight testing matrix" below
Flash the firmware (documented below)
Test
Upload the log (documented below)
Report the test in this issue thread!

📑 Flight testing matrix

📖 Here are the table of things we need tests for.
This will constantly get updated, and your contribution to testing the missing slots (tests needed) will be greatly appreciated!

Title	Description	Vehicle/Hardware requirements	Testing procedure	Related issue/posts
General	By testing your usual setup, we want to capture any regression / weird behaviors you may notice	Any	Test what you usually use for your personal usage, and report it to the comment below
Optical Flow	With optical flow fusion enabled, the preflight failures has been observed.	Any Optical Flow / Capable of either Altitude or Position mode	With Optical Flow enabled, try to arm in altitude or position mode	#20929
~~Random 100% Thrust~~	Due to edge case conditions by land detector & hover thrust estimator, multirotors showed occasional 100% thrust. https://github.com/hendjoshsr71 can reproduce it for now.	Multirotor (with low hover thrust input: e.g. 30%)	Takeoff, land and keep the throttle at low position. Occasionally vehicle will exhibit 100% thrust suddenly and shoot to the sky.	#20275

How to flash v1.14 beta firmware

Open QGC
Click the Q icon on upper right > Vehicle Setup > Firmware (Step 1 in picture)
Connect your flight controller to the computer
When the Firmware setup window pops up, click "Advanced settings" checkbox
Select "Beat Testing (beta)" from the drop down (Step 2 in picture)
Click "Ok"

This should automatically flash & reboot your flight controller with the latest v1.14 beta release!

How to share your log

First, retreive the log from the flight controller in QGC Q icon > Analyze Tools > Log Download, and find the log you want to download.

Then:

Go to https://logs.px4.io/
Click on "Flight Report" tab (this allows public viewing of the log in the browse page)
Add the ULog file
Fill in the description, feedback, and video URL (if available)
Click "Upload"
Copy and paste the link of the log, and share it to this thread

When posting on this thread, please mention what kind of test it was (especially if it is one of the testing matrix options) & general info behind it!

Questions?

Feel free to ask any questions regarding flight testing in the #dev-team channel in the discord server!

ryanjAA · 2023-03-22T18:39:16Z

ryanjAA · 2023-03-22T18:39:39Z

All on 1.14b on FW. :)

junwoo091400 · 2023-03-24T06:46:12Z

Btw, I would like to note that since we agreed to wait for the rebasing of main branch into release/1.14 until we resolve the outstanding issues in our project board: https://github.com/orgs/PX4/projects/45, I'm not sure if we can consider current beta releases as a valid one or not 🤷

MDecarabas · 2023-03-24T23:27:02Z

Hey everyone, did some testing today in a couple of different modes and wrote up some stuff I thought might be of interest.

Manual Mode
Unable to arm because throttle is high when using sbus rc.
-Troubleshooting:
--Tested using telemetry radio with joystick and issue does not occur.
--Tested on 1.13.3 using sbus rc and issue does not occur

Altitude Mode
Only able to arm if throttle is pushed all the way down when using sbus rc. Once armed it will not lower the rpm of the motors
-Troubleshooting:
--Tested using telemetry radio with joystick and behavior does not occur.
--Tested on 1.13.3 using sbus rc and behavior does not occur

Stablized Mode
Same error and troubleshooting as in manual mode

Position Mode
Unable to reduce altitude when in mode. Drone will either keep level if sticks are fully down or rise if sticks are centered.
-Troubleshooting:
--Tested using telemetry radio with joystick and issue does not occur.
--Tested on 1.13.3 using sbus rc and issue does not occur

Attached below are flight logs for the altitude mode and position mode behavior described above. Let me know if I can provide any more clarifying information.

Altitude Mode: https://logs.px4.io/plot_app?log=c597875e-feab-40d4-a633-a709a72dbe99
Position Mode: https://logs.px4.io/plot_app?log=aaeae7c4-4171-472f-8c0e-34a35c91d326

mrpollo · 2023-03-27T18:09:42Z

@junwoo091400 anything tagged v1.14 (beta/rc... etc) or coming from the main branch (before the official release or branching out) should be considered 1.14, and as such the logs are definitely helpful.

jwarnergithub · 2023-04-01T21:46:21Z

https://logs.px4.io/plot_app?log=7324a947-33f9-4c63-a5a1-2ce1c7208560

Flew my hex for a quick few minutes in position mode. No problems noted.

AlexKlimaj · 2023-04-01T22:56:33Z

Looks like there is no beta flash-able for the ARKV6X in QGC.

AlexKlimaj · 2023-04-01T22:59:58Z

Submodule path 'src/lib/events/libevents': checked out '48911e7be752a908a15d945b796ed8d8282b7b02'
fatal: remote error: upload-pack: not our ref bc889afb4c5bf1c0d8ee29ef35eaaf4c8bef8a5d
fatal: Fetched in submodule path 'src/lib/events/libevents/libs/cpp/parse/nlohmann_json', but it did not contain bc889afb4c5bf1c0d8ee29ef35eaaf4c8bef8a5d. Direct fetching of that commit failed.
fatal: 
Submodule path 'src/modules/mavlink/mavlink': checked out '2bdcab78b53d1e349079b43c9d726036abe0617c'
Submodule path 'src/modules/mavlink/mavlink/pymavlink': checked out '2ca2c13b54b4c75dd71c79acafc7ec40d9cb4965'
Submodule path 'src/modules/microdds_client/Micro-XRCE-DDS-Client': checked out '4248559f3b111155c783e524e461ccc83e768103'
fatal: Failed to recurse into submodule path 'src/lib/events/libevents

When checking out the beta and updating submodules.

AlexKlimaj · 2023-04-02T00:31:53Z

This is a 250 quad with ARKV6X, ARK GPS, and ARK Flow. I think my rates tuning was way off to start. The vehicle always wanted to pitch backwards on takeoff. After some rates tuning it seems okay.

@dagar I was able to arm in position mode with optical flow for some reason this time.

https://review.px4.io/plot_app?log=96d5db15-dbcd-4b5e-aa64-f85d6ca41da4
https://review.px4.io/plot_app?log=41dd1b7e-d7bb-410b-8613-35459d9d511a
https://review.px4.io/plot_app?log=59d81ce1-d0d0-4cd5-9bf3-9fc12aeba2d1
https://review.px4.io/plot_app?log=f849d0fd-ca7d-43c1-9126-66eb3e43229b
https://review.px4.io/plot_app?log=7f14891c-ff1e-43e4-b2a8-03e287a77835
https://review.px4.io/plot_app?log=529d077a-cf68-4e15-84a4-e090a83c2003

DronecodeBot · 2023-04-04T15:02:46Z

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-maintainers-call-april-04-2023/31415/1

bresch · 2023-04-05T12:54:18Z

@MDecarabas Thanks for the tests. I inspected the altitude issue and the drone is constantly climbing because the GNSS altitude tells that the drone is actually descending (compared to the baro that seems to be more reasonable).

You could change the height reference to baro (`EKF2_HGT_REF) to lower the effect of the GNSS height drift or even disable the GNSS height fusion to let the baro do the job alone (EKF2_GPS_CTRL). See https://docs.px4.io/main/en/advanced_config/tuning_the_ecl_ekf.html#height for more details.

DronecodeBot · 2023-04-05T15:36:47Z

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-community-q-a-april-05-2023/31435/1

DronecodeBot · 2023-04-05T16:49:04Z

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/v1-14-beta-call-for-flight-testing/31551/1

DronecodeBot · 2023-04-11T15:03:45Z

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-maintainers-call-april-11-2023/31524/1

AlexKlimaj · 2023-04-11T20:31:28Z

This is a 250 quad with ARKV6X, ARK GPS, and ARK Flow. Very windy day.

https://review.px4.io/plot_app?log=1263490b-aecf-420e-af44-b1013802bd0a
https://review.px4.io/plot_app?log=6be883f2-33c3-4ff6-bf35-94cdf3981903
https://review.px4.io/plot_app?log=ca9e8974-febe-437e-bdae-7fc196c51f51

650 quad with ARKV6X, Dual ARK RTK GPS, ARK Flow, and a dronecan smart battery. Moving baseline for yaw. Very windy.

https://review.px4.io/plot_app?log=95943f96-4039-4b80-ad57-92311a29e532
https://review.px4.io/plot_app?log=20877cb1-6949-4813-8e25-30ce7d3a8d48

Different 250 quad with Pixhawk 4 Mini, ARK GPS, and ARK Flow Rev 3 with PAA3905 and AFBR_S50LX85D. Very windy day.

https://review.px4.io/plot_app?log=0b1a730d-147b-47e3-b25e-c56fe27dacf8

The optical flow bug is still an issue when the sensor is touching the ground. On the two vehicles with longer legs, I am able to arm.

junwoo091400 · 2023-04-12T15:13:03Z

From sturner in discord: https://discord.com/channels/1022170275984457759/1022185721450213396/1092830779429625977

Just tested with latest 1.14 and an ARK Flow. Possible that we have other issues with our configuration. This is with external vision inputs enabled where we are able to arm:
https://review.px4.io/plot_app?log=731de912-a5cb-4271-a868-ea927bd73f3b

With external vision inputs disabled, we are unable to arm: https://review.px4.io/plot_app?log=c2b658cc-72ea-4b9f-9153-c13852865406

abarcis · 2023-04-27T17:22:05Z

We are preparing for tests with 1.14.0-beta2 and we experienced the same issues as the ones described by @MDecarabas #21358 (comment) We are working with fixedwings, so I cannot fully reproduce everything, but, in particular, we were also experiencing a similar problem when trying to arm in manual mode: "Unable to arm because throttle is high when using sbus rc.".

When debugging, we've realized that manual_control_setpoint orb topic contained throttle from 0 to 1 and I understand that in 1.14 it should be from -1 to 1. After some extensive debugging and trying random things, we've managed to make it work; we think the problem was related to the fact that throttle output of RC was inverted. @MDecarabas can you maybe confirm if your RC was also set to invert throttle?

junwoo091400 · 2023-05-04T07:35:17Z

Tested with the main branch commit on ATL Mantis Edu (Quadcopter) today.

Yaw estimate error bug test
https://logs.px4.io/plot_app?log=ca3cafd0-2487-4df6-868b-4901eef31808

The same error didn't occur, meaning between 1.14 beta & main branch, some change happened that fixed this behavior.

Random 100% thrust issue test
As detailed in this comment: #20275 (comment)

I couldn't reproduce the random 100% thrust scenario.

https://logs.px4.io/plot_app?log=60f24c0a-d422-472e-b5ff-2cea91ec4978
https://logs.px4.io/plot_app?log=5fb34f03-6441-4156-aabe-d98502ed6d9f

abarcis · 2023-05-05T13:50:38Z

A few of our flights with a fixed-wing model. All done with 1.14.0-beta2.
Stabilized + mission mode:
https://logs.px4.io/plot_app?log=7aca6a10-1042-4254-9d9b-988763adc4c1
https://logs.px4.io/plot_app?log=9263f8b8-8ea5-4fab-b2c5-4068ed5a6be9
Stabilized + mission + offboard:
https://logs.px4.io/plot_app?log=ac132a77-7494-42ec-bf05-e940d580967f

During the flights, everything went smoothly. The only problem we had was with calibrating RC with the inverted throttle as mentioned in one of the comments above. Is it a known problem, or should we raise it as an issue?

abarcis · 2023-05-10T16:39:44Z

We are preparing for tests with 1.14.0-beta2 and we experienced the same issues as the ones described by @MDecarabas #21358 (comment) We are working with fixedwings, so I cannot fully reproduce everything, but, in particular, we were also experiencing a similar problem when trying to arm in manual mode: "Unable to arm because throttle is high when using sbus rc.".

When debugging, we've realized that manual_control_setpoint orb topic contained throttle from 0 to 1 and I understand that in 1.14 it should be from -1 to 1. After some extensive debugging and trying random things, we've managed to make it work; we think the problem was related to the fact that throttle output of RC was inverted. @MDecarabas can you maybe confirm if your RC was also set to invert throttle?

I've raised the PR #21576 which solves this problem.

ryanjAA · 2023-08-25T11:04:44Z

Hardfault - same commit as above flights. Flight before this (10 min before) was fine.
https://review.px4.io/plot_app?log=869b08de-15df-4f10-8958-cb33a26ced91

yikes. on the flight before though.. were you able to test runway landing @ryanjAA (potentially with this PR #21988)? would be awesome to have flight validation of the fix before we get this merged in.

Flight before was completely fine and from takeoff to landing in mission but it doesn’t have PR 21988 in it. I should have been more clear, same pr as above meaning same as the previous flights I posted.

ryanjAA · 2023-08-25T11:07:13Z

The hardfault is an imprecise busfault, therefore I do not have an exact address which is a shame. The backtrace points to an issue freeing memory inside the heap while exiting from a mavlink_main task.

(gdb) bt
#0  mm_addfreechunk (heap=heap@entry=0x2400f2e0, node=0x3000f9c8) at mm_heap/mm_addfreechunk.c:58
#1  0x0802cffe in mm_free (heap=0x2400f2e0, mem=0x3000fce0) at mm_heap/mm_free.c:175
#2  0x0802cd42 in free (mem=<optimized out>) at umm_heap/umm_free.c:49
#3  0x08025812 in task_uninit_info (group=group@entry=0x30010180) at tls/task_uninitinfo.c:53
#4  0x08024ed2 in group_release (group=0x30010180) at group/group_leave.c:425
#5  group_leave (tcb=tcb@entry=0x300100d0) at group/group_leave.c:425
#6  0x08024a1e in nxtask_exithook (tcb=0x300100d0, status=status@entry=0, nonblocking=nonblocking@entry=false) at task/task_exithook.c:502
#7  0x08024ace in _exit (status=status@entry=0) at task/exit.c:76
#8  0x08022568 in exit (status=0) at stdlib/lib_exit.c:54
#9  0x0802d68e in nxtask_startup (entrypt=0x0, entrypt@entry=0x80f2221 <mavlink_main(int, char**)+24>, argc=4, argv=0x30014b68) at sched/task_startup.c:70
#10 0x080249ea in nxtask_start () at task/task_start.c:134
#11 0x00000000 in ?? ()

However, since the busfault is imprecise and due to the STM32H7's cache architecture, the access may be delayed, thus the code may not actually be the ones doing the access.

The values inside the registers also do not look unreasonable, I don't see any blatent out-of-bounds access of volatile memories:

(gdb) i r
r0             0x2400f2e0          604041952
r1             0x3000f9c8          805370312
r2             0x3000fd78          805371256
r3             0x3000f9c8          805370312
r4             0x3000fce0          805371104
r5             0x2400f2e0          604041952
r6             0x2400f330          604042032
r7             0x0                 0
r8             0x0                 0
r9             0x0                 0
r10            0x0                 0
r11            0x0                 0
r12            0x0                 0
sp             0x300152f0          0x300152f0
lr             0x802cfff           134402047
pc             0x802cf00           0x802cf00 <mm_addfreechunk>
xpsr           0x1000000           16777216

Thanks a lot for doing that. Appreciate the work!

Too bad there is nothing point to something clear.

Not sure what to think/do at this point.

Muammer06 · 2023-08-25T11:28:30Z

hello guys I wanna share my logs from my quad copter's successful and unsuccessful fligths. It has a body made by ourselves, around 35kg.
I would be grateful if you could give advice for the next flight about the recent crash for me and point out potential errors.

Px4 version=v1.14.0 (RC) ([5359fe5]
Airframe: Generic QuadcopterQuadrotor x (4001)
Hardware: CUBEPILOT_CUBEORANGEPLUS

my first look from good flight. it is fly very good in mission mode and returned with pilot.
https://review.px4.io/plot_app?log=20f86e41-246c-4f46-a5e6-74c5a83e845b

after 4 5 hours. we try to fly without change anything.
in first, we forget the plugging water sprayer and returned with return mode. very succesfull.
https://review.px4.io/plot_app?log=525d6cb2-d1cb-4c02-a7ef-cf99740c9c7c

after we plugging. we start the mission and we see something wrong we landed with manuel.
https://logs.px4.io/plot_app?log=9124c492-8820-4142-87db-a44481eeb119

and I reupload mission again. nothing change. frame and all electronics looking okey.
but unfortunately after start mission. it going to crash. I see local position invalid at failsafe flags in log.
https://logs.px4.io/plot_app?log=9c5d3cb8-838c-4d6e-9c08-cf445a898725

Our drone video while flying:
https://drive.google.com/file/d/1MgnJ9bGEpbA3gbGcenjSPh37csj2iUU2/view?usp=sharing

julianoes · 2023-08-25T23:12:56Z

I see local position invalid at failsafe flags in log.
https://logs.px4.io/plot_app?log=9c5d3cb8-838c-4d6e-9c08-cf445a898725

Exactly, I wonder why. The GPS itself looks fine. Any idea @bresch?

Now when it comes to the crash, it looks to me like it run out of battery. The voltage suddenly plummets, doesn't it?

ryanjAA · 2023-08-25T23:25:00Z

I see local position invalid at failsafe flags in log.
https://logs.px4.io/plot_app?log=9c5d3cb8-838c-4d6e-9c08-cf445a898725

Exactly, I wonder why. The GPS itself looks fine. Any idea @bresch?

Now when it comes to the crash, it looks to me like it run out of battery. The voltage suddenly plummets, doesn't it?

Could something be loose? Vibration is so high first vs last flight.

ryanjAA · 2023-08-25T23:25:28Z

The hardfault is an imprecise busfault, therefore I do not have an exact address which is a shame. The backtrace points to an issue freeing memory inside the heap while exiting from a mavlink_main task.

(gdb) bt
#0  mm_addfreechunk (heap=heap@entry=0x2400f2e0, node=0x3000f9c8) at mm_heap/mm_addfreechunk.c:58
#1  0x0802cffe in mm_free (heap=0x2400f2e0, mem=0x3000fce0) at mm_heap/mm_free.c:175
#2  0x0802cd42 in free (mem=<optimized out>) at umm_heap/umm_free.c:49
#3  0x08025812 in task_uninit_info (group=group@entry=0x30010180) at tls/task_uninitinfo.c:53
#4  0x08024ed2 in group_release (group=0x30010180) at group/group_leave.c:425
#5  group_leave (tcb=tcb@entry=0x300100d0) at group/group_leave.c:425
#6  0x08024a1e in nxtask_exithook (tcb=0x300100d0, status=status@entry=0, nonblocking=nonblocking@entry=false) at task/task_exithook.c:502
#7  0x08024ace in _exit (status=status@entry=0) at task/exit.c:76
#8  0x08022568 in exit (status=0) at stdlib/lib_exit.c:54
#9  0x0802d68e in nxtask_startup (entrypt=0x0, entrypt@entry=0x80f2221 <mavlink_main(int, char**)+24>, argc=4, argv=0x30014b68) at sched/task_startup.c:70
#10 0x080249ea in nxtask_start () at task/task_start.c:134
#11 0x00000000 in ?? ()

However, since the busfault is imprecise and due to the STM32H7's cache architecture, the access may be delayed, thus the code may not actually be the ones doing the access.
The values inside the registers also do not look unreasonable, I don't see any blatent out-of-bounds access of volatile memories:

(gdb) i r
r0             0x2400f2e0          604041952
r1             0x3000f9c8          805370312
r2             0x3000fd78          805371256
r3             0x3000f9c8          805370312
r4             0x3000fce0          805371104
r5             0x2400f2e0          604041952
r6             0x2400f330          604042032
r7             0x0                 0
r8             0x0                 0
r9             0x0                 0
r10            0x0                 0
r11            0x0                 0
r12            0x0                 0
sp             0x300152f0          0x300152f0
lr             0x802cfff           134402047
pc             0x802cf00           0x802cf00 <mm_addfreechunk>
xpsr           0x1000000           16777216

Thanks a lot for doing that. Appreciate the work!

Too bad there is nothing point to something clear.

Not sure what to think/do at this point.

Is there anything else that can be done past this?

Muammer06 · 2023-08-26T09:13:30Z

@julianoes
When the battery voltage drops to the zero, it happens when we suddenly disconnect the battery cable. Since I have a battery created by connecting 2 batteries in series, I have observed such a voltage drop from high to low before.

@ryanjAA
We manually check the mechanics before each flight, so there can be no abnormal changes in the fuselage. Likewise, when I opened it today, I did not find any loose or moving parts.

today I will fly with my pixhawk 4 + 2 GPS and 1.14 version and changed RC transmitter.

tstastny · 2023-08-28T20:01:55Z

@dagar @KonradRudin while SITL testing this fix #21988

I found another corner case where takeoff command engaged trim throttle somehow with no valid position setpoint and led to fly-away -- im assuming because i hadnt re-uploaded the mission on the first go after building, and tecs was likely initialized at some point with trim throttle. Then it stayed in FW_POSCTRL_MODE_OTHER, which recently now keeps the previous throttle setpoint (vaguely recall this being done to avoid setpoint jumps from race conditions)

PX4-Autopilot/src/modules/fw_pos_control/FixedwingPositionControl.cpp

Lines 2365 to 2366 in 0f260fc

    
           case FW_POSCTRL_MODE_OTHER: { 
        
           		_att_sp.thrust_body[0] = min(_att_sp.thrust_body[0], _param_fw_thr_max.get());

Flags on arm indicating this would fall into FW_POSCTRL_MODE_OTHER:

in this snippet:

PX4-Autopilot/src/modules/fw_pos_control/FixedwingPositionControl.cpp

Lines 714 to 812 in 0f260fc

    
           	if (((_control_mode.flag_control_auto_enabled && _control_mode.flag_control_position_enabled) || 
        
           	     _control_mode.flag_control_offboard_enabled) && _position_setpoint_current_valid) { 
        
           		if (_pos_sp_triplet.current.type == position_setpoint_s::SETPOINT_TYPE_TAKEOFF) { 
        
           			if (_vehicle_status.is_vtol && _vehicle_status.in_transition_mode) { 
        
           				_control_mode_current = FW_POSCTRL_MODE_AUTO; 
        
           				// in this case we want the waypoint handled as a position setpoint -- a submode in control_auto() 
        
           				_pos_sp_triplet.current.type = position_setpoint_s::SETPOINT_TYPE_POSITION; 
        
           			} else { 
        
           				_control_mode_current = FW_POSCTRL_MODE_AUTO_TAKEOFF; 
        
           				if (commanded_position_control_mode != FW_POSCTRL_MODE_AUTO_TAKEOFF && !_landed) { 
        
           					// skip takeoff detection when switching from any other mode, auto or manual, 
        
           					// while already in air. 
        
           					// TODO: find a better place for / way of doing this 
        
           					_skipping_takeoff_detection = true; 
        
           				} 
        
           			} 
        
           		} else if (_pos_sp_triplet.current.type == position_setpoint_s::SETPOINT_TYPE_LAND) { 
        
           			if (!_vehicle_status.in_transition_mode) { 
        
           				// Use _position_setpoint_previous_valid to determine if landing should be straight or circular. 
        
           				// Straight landings are currently only possible in Missions, and there the previous WP 
        
           				// is valid, and circular ones are used outside of Missions, as the land mode sets prev_valid=false. 
        
           				if (_position_setpoint_previous_valid) { 
        
           					_control_mode_current = FW_POSCTRL_MODE_AUTO_LANDING_STRAIGHT; 
        
           				} else { 
        
           					_control_mode_current = FW_POSCTRL_MODE_AUTO_LANDING_CIRCULAR; 
        
           				} 
        
           			} else { 
        
           				// in this case we want the waypoint handled as a position setpoint -- a submode in control_auto() 
        
           				_pos_sp_triplet.current.type = position_setpoint_s::SETPOINT_TYPE_POSITION; 
        
           			} 
        
           		} else { 
        
           			_control_mode_current = FW_POSCTRL_MODE_AUTO; 
        
           		} 
        
           	} else if (_control_mode.flag_control_auto_enabled 
        
           		   && _control_mode.flag_control_climb_rate_enabled 
        
           		   && _control_mode.flag_armed // only enter this modes if armed, as pure failsafe modes 
        
           		   && !_control_mode.flag_control_position_enabled) { 
        
           		// failsafe modes engaged if position estimate is invalidated 
        
           		if (commanded_position_control_mode != FW_POSCTRL_MODE_AUTO_ALTITUDE 
        
           		    && commanded_position_control_mode != FW_POSCTRL_MODE_AUTO_CLIMBRATE) { 
        
           			// reset timer the first time we switch into this mode 
        
           			_time_in_fixed_bank_loiter = now; 
        
           		} 
        
           		if (hrt_elapsed_time(&_time_in_fixed_bank_loiter) < (_param_nav_gpsf_lt.get() * 1_s) 
        
           		    && !_vehicle_status.in_transition_mode) { 
        
           			if (commanded_position_control_mode != FW_POSCTRL_MODE_AUTO_ALTITUDE) { 
        
           				// Need to init because last loop iteration was in a different mode 
        
           				events::send(events::ID("fixedwing_position_control_fb_loiter"), events::Log::Critical, 
        
           					     "Start loiter with fixed bank angle"); 
        
           			} 
        
           			_control_mode_current = FW_POSCTRL_MODE_AUTO_ALTITUDE; 
        
           		} else { 
        
           			if (commanded_position_control_mode != FW_POSCTRL_MODE_AUTO_CLIMBRATE && !_vehicle_status.in_transition_mode) { 
        
           				events::send(events::ID("fixedwing_position_control_descend"), events::Log::Critical, "Start descending"); 
        
           			} 
        
           			_control_mode_current = FW_POSCTRL_MODE_AUTO_CLIMBRATE; 
        
           		} 
        
           	} else if (_control_mode.flag_control_manual_enabled && _control_mode.flag_control_position_enabled) { 
        
           		if (commanded_position_control_mode != FW_POSCTRL_MODE_MANUAL_POSITION) { 
        
           			/* Need to init because last loop iteration was in a different mode */ 
        
           			_hdg_hold_yaw = _yaw; // yaw is not controlled, so set setpoint to current yaw 
        
           			_hdg_hold_enabled = false; // this makes sure the waypoints are reset below 
        
           			_yaw_lock_engaged = false; 
        
           			/* reset setpoints from other modes (auto) otherwise we won't 
        
           			 * level out without new manual input */ 
        
           			_att_sp.roll_body = _manual_control_setpoint.roll * radians(_param_fw_r_lim.get()); 
        
           			_att_sp.yaw_body = _yaw; // yaw is not controlled, so set setpoint to current yaw 
        
           		} 
        
           		_control_mode_current = FW_POSCTRL_MODE_MANUAL_POSITION; 
        
           	} else if (_control_mode.flag_control_manual_enabled && _control_mode.flag_control_altitude_enabled) { 
        
           		_control_mode_current = FW_POSCTRL_MODE_MANUAL_ALTITUDE; 
        
           	} else { 
        
           		_control_mode_current = FW_POSCTRL_MODE_OTHER; 
        
           	}

log: https://review.px4.io/plot_app?log=98c21633-7be5-4ce4-a77f-45baf6b19990

Brain is fried for tonight. Will need to look at this tomorrow. If you have any ideas for a patch that isnt a complete refactor... very open to recommendations.

We REALLY need to do a broad refactoring of FixedWingPositionControl for 1.15 to clean up state machine and APIs ... and unit/integration test the hell out of it so it cant devolve again.

tstastny · 2023-08-28T20:25:22Z

@dagar - another tangent.. (scope is creeping quickly here) - we totally let this one slip some time ago #21581 -- i didnt want to hack in the bool as it's done there.. but it would be the safest way to get the proper airspeed septoints for takeoff into this release. i can take this one back up again tomorrow as well.

VTOLDavid · 2023-09-01T12:34:30Z

Hi, I have been trying to configure a quad tailsitter on RC-1, using a cubeblack and last QGC V4.2.8. I have bench tested it and found this:

1-Can't calibrate ESCs in the new range, since cubeorange and black do not work in QGC in windows via USB. I managed to calibrate 3 ESCs using the actuator testing but 3 motors spin at idle an one is stopped. Finally I calibrated the ESCs using a servo tester. All other calibrations done via telemetry.

2- The message Critical: Preflight: CPU load too high: 95.2% appears several times

3- I was not able to configure properly the elevons gain. Actuators/ Pich & Yaw Scale does not seem to work. Elevons move with random gains with different values of the parameters set.

Both elevons same movement in pitch with different gains:
CA_SV_CS0_TRQ_P=0.5
CA_SV_CS0_TRQ_Y=0.45
CA_SV_CS1_TRQ_P =0.01
CA_SV_CS1_TRQ_Y)=-0.45
https://logs.px4.io/plot_app?log=6d2e2b52-5fd3-4488-a51a-f28154033ac1

Movement not proportional to gain:
CA_SV_CS0_TRQ_P=0.5
CA_SV_CS0_TRQ_Y=0.04
CA_SV_CS1_TRQ_P =0.1
CA_SV_CS1_TRQ_Y)=-0.45
https://logs.px4.io/plot_app?log=ad4acf76-b026-43a4-b7c4-921e26bf73c0

CA_SV_CS0_TRQ_P=0.5
CA_SV_CS0_TRQ_Y=0.45
CA_SV_CS1_TRQ_P =0.01
CA_SV_CS1_TRQ_Y)=-0.45
https://logs.px4.io/plot_app?log=2cc019ae-7c0b-448e-b0cd-1b8bd03dc21b

4- It can't do the transition on stabilize.

5- It does not perfom the transition properly in alt hold.
Motor off in FW: https://logs.px4.io/plot_app?log=b23eb4ba-0111-4961-a8b7-8a4ecf8e5d42
Elevons full deflection: https://logs.px4.io/plot_app?log=0b548473-8a68-4742-ad48-dbbdee505ff9

5- Preflight fail on flight on FW mode:
https://logs.px4.io/plot_app?log=aaba064a-e552-4c18-a0d7-c24eda956470

jstrebel · 2023-09-11T07:25:40Z

I made autolanding Tests with the fix #21988
Flight was OK. ( Before touching the ground, I Took over to Manual)

Observations in all three flights:
I see in the log many Failsafe flags and fd critical failure messages.
and repetitively the warning: health_and_arming checks.
Preflight fail Attitude failure (roll)

WARN [health_and_arming_checks] Preflight Fail: height estimate not stable

Flight 1 Handlauch (Manual, stabilized, Mission)
Apology this file is large, I forgot to stop logging after landing
https://review.px4.io/plot_app?log=0109b524-ae37-43db-ac9d-2f3344ce8513

Flight 2 Handlauch (Manual, stabilized, Mission)
https://review.px4.io/plot_app?log=a5c54ef2-b228-411f-9f02-2eb726fb963c

Flight 3 Launch direct into Mission
https://review.px4.io/plot_app?log=6e17183c-4fa5-48d9-9c25-54025f60590c

AlexKlimaj · 2023-09-15T17:24:11Z

It was always slowly yawing to the north.
https://review.px4.io/plot_app?log=9b65dc13-87f4-44e3-84ea-285e25a9a017

Did a mag cal and this is slightly better. Still has the bug where it slowly descends until it lands.
https://review.px4.io/plot_app?log=26a34e80-6518-4130-9456-0fd60d24b7e3

sfuhrer · 2023-09-18T09:41:46Z

@VTOLDavid thanks for the test, here some feedback for your raised points:

2- The message Critical: Preflight: CPU load too high: 95.2% appears several times

Could it have been triggered by parameter changes? Then it's not concerning. The average load in your shared logs seems okay (80% max).

3- I was not able to configure properly the elevons gain. Actuators/ Pich & Yaw Scale does not seem to work. Elevons move with random gains with different values of the parameters set.

What did you try to achieve with the tuning of the elevon gains? I would recommend to leave them as default and then tune the responsiveness of the controller through the PID gains of the fixed-wing rate controller (which is the controller controlling the elevons).
Do not confuse actuator effectiveness scales with gains; reducing a effectiveness scale leads to a higher deflection as the actuator has to move more to achieve the same effect.

4- It can't do the transition on stabilize.

In Stabilized mode you have to manually pitch forward until the transition pitch is achieved and the airspeed is reached. Were you aware of that and is the issue something else?

5- It does not perfom the transition properly in alt hold.
Motor off in FW: https://logs.px4.io/plot_app?log=b23eb4ba-0111-4961-a8b7-8a4ecf8e5d42
Elevons full deflection: https://logs.px4.io/plot_app?log=0b548473-8a68-4742-ad48-dbbdee505ff9

That sounds severe. I also noticed that in your logs the attitude and rate setpoints are not logged, which could be related. I will check this further.

6- Preflight fail on flight on FW mode:

It's due to pitch angle errors. The first time in FW (I guess that can be expected with the issues noted in 5), and then the second right after the backtransition is over.

sfuhrer · 2023-09-19T14:52:58Z

That sounds severe. I also noticed that in your logs the attitude and rate setpoints are not logged, which could be related. I will check this further.

It looks like the issue is that you don't have a valid global position, and thus no Home position resp. local_position.ref_alt is not set. We don't handle that in the FW position controller cleanly (the controller needs absolute altitude, and thus in your case gets a NAN as input).
@VTOLDavid You don't have a GPS on your drone, correct?

@tstastny fyi. Not sure how simple this is to patch, but Altitude mode should be supported when flying without GPS.

VTOLDavid · 2023-09-21T14:51:41Z

@VTOLDavid thanks for the test, here some feedback for your raised points:

2- The message Critical: Preflight: CPU load too high: 95.2% appears several times

Could it have been triggered by parameter changes? Then it's not concerning. The average load in your shared logs seems okay (80% max).

I do not remember changing any parameters when that message was shown, but that error has not being shown again in later tests

3- I was not able to configure properly the elevons gain. Actuators/ Pich & Yaw Scale does not seem to work. Elevons move with random gains with different values of the parameters set.

What did you try to achieve with the tuning of the elevon gains? I would recommend to leave them as default and then tune the responsiveness of the controller through the PID gains of the fixed-wing rate controller (which is the controller controlling the elevons). Do not confuse actuator effectiveness scales with gains; reducing a effectiveness scale leads to a higher deflection as the actuator has to move more to achieve the same effect.

I want to have the following gains:

          MOTORS                  ELEVONS
      YAW  PITCH  ROLL    YAW PITCH ROLL  (MC reference system)
MC:   0.5    1     1      1    0.5    -             
FW:    -     -     -      Gains from FW controller

We need full deflection of elevons for Yaw in MC and small deflection in pitch, but use the FW controler gains FW flight.

For example, how can I get this configuration in the new system?

R: 4x 10000 10000 5000 0

Z:

# left elevon
M: 2
S: 1 0  3000  5000      0 -10000  10000
S: 1 1  2500  2500      0 -10000  10000

# right elevon
M: 2
S: 1 0   3000   5000    0 -10000  10000
S: 1 1  -2500  -2500    0 -10000  10000

4- It can't do the transition on stabilize.

In Stabilized mode you have to manually pitch forward until the transition pitch is achieved and the airspeed is reached. Were you aware of that and is the issue something else?

I had no idea about this. What parameter defines transition pitch? How is the procedure? Switch to FW mode an then pitch forward to accelerate?

5- It does not perfom the transition properly in alt hold.
Motor off in FW: https://logs.px4.io/plot_app?log=b23eb4ba-0111-4961-a8b7-8a4ecf8e5d42
Elevons full deflection: https://logs.px4.io/plot_app?log=0b548473-8a68-4742-ad48-dbbdee505ff9

That sounds severe. I also noticed that in your logs the attitude and rate setpoints are not logged, which could be related. I will check this further.

6- Preflight fail on flight on FW mode:

It's due to pitch angle errors. The first time in FW (I guess that can be expected with the issues noted in 5), and then the second right after the backtransition is over.

But how is possible that it gives a preflight fail if it is armed?

VTOLDavid · 2023-09-21T14:57:15Z

It looks like the issue is that you don't have a valid global position, and thus no Home position resp. local_position.ref_alt is not set. We don't handle that in the FW position controller cleanly (the controller needs absolute altitude, and thus in your case gets a NAN as input). @VTOLDavid You don't have a GPS on your drone, correct?

@sfuhrer We usually have GPS, but we fly stabilize and alt hold modes without GPS to be sure we can still fly if GPS fails.

AlexKlimaj · 2023-10-02T23:40:30Z

Test hop of an old quad that I just converted to an ARKV6X. 6s, Here3, gimbal.

https://review.px4.io/plot_app?log=c6db6c7d-255c-46f9-b49d-5c8f83dd6e6a

sfuhrer · 2023-10-03T07:43:15Z

@VTOLDavid

We need full deflection of elevons for Yaw in MC and small deflection in pitch, but use the FW controler gains FW flight.
For example, how can I get this configuration in the new system?

If you want more deflection for yaw then for pitch you can reduce the yaw effectiveness and increase the pitch one. E.g. 0.3 and 0.7.

I had no idea about this. What parameter defines transition pitch?

It is currently hard-coded to 60°. Would you want to be able to tune it and thus would rather want a parameter for it?

How is the procedure? Switch to FW mode an then pitch forward to accelerate?

Yes exactly. It's been like that for a while now but I also don't like it that much, I'm thinking about also doing the automatic pitch ramp in Stabilized.

But how is possible that it gives a preflight fail if it is armed?

The "preflight" shouldn't be in the message, agree.

VTOLDavid · 2023-10-03T12:15:36Z

@sfuhrer

@VTOLDavid

We need full deflection of elevons for Yaw in MC and small deflection in pitch, but use the FW controler gains FW flight.
For example, how can I get this configuration in the new system?

If you want more deflection for yaw then for pitch you can reduce the yaw effectiveness and increase the pitch one. E.g. 0.3 and 0.7.

I will test it. Have you tested if the deflection of the surfaces for a tailsitter is correct? I saw a very random behaviour in my tests. You have the logs in one of the previous posts.

I had no idea about this. What parameter defines transition pitch?

It is currently hard-coded to 60°. Would you want to be able to tune it and thus would rather want a parameter for it?

How is the procedure? Switch to FW mode an then pitch forward to accelerate?

Yes exactly. It's been like that for a while now but I also don't like it that much, I'm thinking about also doing the automatic pitch ramp in Stabilized.

As I understand for transition to FW you need:

Transition switch in FW
Pitch angle must be greather than 60º
Speed over transition speed

Once the conditions are meet direct change to FW

Is that correct?

Back transition to MC is as usual, using the transition switch?

I see 2 problems:

Plane does not pitches down violently once the transition is done? The RC would be full pitch down. (Maybe you solved this in software)
You may need a very large MPC_MAN_TILT_MAX angle to reach transition speed in some airframes. If it is configured up to 80º, assuming a stall angle of attack of 10º, the control in MC in stabilize would be super sensitive for pitch and roll. Maybe a parameter for set maximum pitch with FW switch triggered? (By the way, would be nice to have 2 parameters to limit the maximum pitch and the maximum roll, separately. In a tailsitter is need a large pitch for fight against wind but not roll).

I like very much the v1.12 pitch ramp approach in Stabilized where you can control thrust. Is very helpful for tuning the transition of large or high speed stall speed UAVs, where you have very narrow range between stall and airframe damaging G forces. Specially the transition back, where if it is done too slow the plane can stall and if it is too fast the airframe can be damaged. In these tests if pilot can control thrust can avoid a crash.
Doing these tests pitching manually would be very difficult.

AlexKlimaj · 2023-10-05T18:22:50Z

I think we might have a big release blocker in that camera trigger and capture do not appear to be working in 1.14.

ryanjAA · 2023-10-05T18:23:48Z

I think we might have a big release blocker in that camera trigger and capture do not appear to be working in 1.14.

Ugh - ya thats an important one.

jstrebel · 2023-10-11T11:21:17Z

Several short FW Missions to “play” with autloand Parameters

junwoo091400 · 2023-11-03T03:52:39Z

Thank you to everyone who contributed in the v1.14 beta testing! @mrpollo shall we close this issue?

mrpollo · 2023-11-03T17:47:25Z

Thanks @junwoo091400 and everyone else who helped get this out the door the release is out and we can finally close this issue 🎉

DronecodeBot · 2023-11-30T02:36:38Z

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/cube-o-px4-v1-14-0-erroneous-pitch-roll-setpoint-in-autonomous-mode/35557/4

mrpollo added bug-report Documentation 📑 Anything improving the documentation of the code / ecosystem [ARCHIVED] Discussion (Use "Discussion needed") and removed bug-report labels Mar 22, 2023

junwoo091400 pinned this issue Mar 24, 2023

junwoo091400 changed the title ~~v1.14 Release Log Archive~~ v1.14 - Flight testing & Issues list Mar 24, 2023

mrpollo changed the title ~~v1.14 - Flight testing & Issues list~~ [v1.14 Release] - Flight testing & Flight Issues (logs) Apr 4, 2023

junwoo091400 changed the title ~~[v1.14 Release] - Flight testing & Flight Issues (logs)~~ [v1.14 beta] - Flight testing & Flight Issues (logs) Apr 5, 2023

junwoo091400 mentioned this issue May 4, 2023

[v1.14 Release] beta: Yaw estimate error in ATL Mantis Edu #21387

Closed

dirksavage88 mentioned this issue May 8, 2023

Pre flight failure with Optical Flow on Ground #20929

Closed

tstastny mentioned this issue Sep 12, 2023

[Bug] Mission start command sets idle after reboot instead of takeoff #22072

Closed

sfuhrer mentioned this issue Sep 19, 2023

FW Positon Controller: set references to 0 if not provided by local_position #22101

Merged

mrpollo closed this as completed Nov 3, 2023

junwoo091400 unpinned this issue Nov 5, 2023

sfuhrer mentioned this issue Nov 6, 2023

Tailsitter VTOL: do automatic pitch ramp in Stabilized mode transitions #22316

Closed

[v1.14 Release Candidate] - Flight testing & Flight Issues (logs) #21358

[v1.14 Release Candidate] - Flight testing & Flight Issues (logs) #21358

Comments

mrpollo commented Mar 22, 2023 • edited Loading

❗ About

Pending Issues

❓ Why we need flight testing

🤷 How you can help with flight testing

📑 Flight testing matrix

How to flash v1.14 beta firmware

How to share your log

Questions?

ryanjAA commented Mar 22, 2023

ryanjAA commented Mar 22, 2023

junwoo091400 commented Mar 24, 2023

MDecarabas commented Mar 24, 2023

mrpollo commented Mar 27, 2023

jwarnergithub commented Apr 1, 2023

AlexKlimaj commented Apr 1, 2023

AlexKlimaj commented Apr 1, 2023

AlexKlimaj commented Apr 2, 2023 • edited Loading

DronecodeBot commented Apr 4, 2023

bresch commented Apr 5, 2023

DronecodeBot commented Apr 5, 2023

DronecodeBot commented Apr 5, 2023

DronecodeBot commented Apr 11, 2023

AlexKlimaj commented Apr 11, 2023 • edited Loading

junwoo091400 commented Apr 12, 2023

abarcis commented Apr 27, 2023

junwoo091400 commented May 4, 2023 • edited Loading

abarcis commented May 5, 2023

abarcis commented May 10, 2023

ryanjAA commented Aug 25, 2023 • edited Loading

ryanjAA commented Aug 25, 2023

Muammer06 commented Aug 25, 2023

julianoes commented Aug 25, 2023

ryanjAA commented Aug 25, 2023

ryanjAA commented Aug 25, 2023

Muammer06 commented Aug 26, 2023

tstastny commented Aug 28, 2023 • edited Loading

tstastny commented Aug 28, 2023

VTOLDavid commented Sep 1, 2023 • edited Loading

jstrebel commented Sep 11, 2023

AlexKlimaj commented Sep 15, 2023

sfuhrer commented Sep 18, 2023

sfuhrer commented Sep 19, 2023 • edited Loading

VTOLDavid commented Sep 21, 2023

VTOLDavid commented Sep 21, 2023

AlexKlimaj commented Oct 2, 2023

sfuhrer commented Oct 3, 2023

VTOLDavid commented Oct 3, 2023

AlexKlimaj commented Oct 5, 2023

ryanjAA commented Oct 5, 2023

jstrebel commented Oct 11, 2023 • edited Loading

junwoo091400 commented Nov 3, 2023

mrpollo commented Nov 3, 2023

DronecodeBot commented Nov 30, 2023

mrpollo commented Mar 22, 2023 •

edited

Loading

AlexKlimaj commented Apr 2, 2023 •

edited

Loading

AlexKlimaj commented Apr 11, 2023 •

edited

Loading

junwoo091400 commented May 4, 2023 •

edited

Loading

ryanjAA commented Aug 25, 2023 •

edited

Loading

tstastny commented Aug 28, 2023 •

edited

Loading

VTOLDavid commented Sep 1, 2023 •

edited

Loading

sfuhrer commented Sep 19, 2023 •

edited

Loading

jstrebel commented Oct 11, 2023 •

edited

Loading