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

mrpollo commented 1 year ago

:exclamation: 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: https://github.com/PX4/PX4-Autopilot/issues/21358#issuecomment-1629618613

❓ 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!

:bookmark_tabs: 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	https://github.com/PX4/PX4-Autopilot/issues/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.	https://github.com/PX4/PX4-Autopilot/issues/20275

How to flash v1.14 beta firmware

beta_flashing

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.

log_uploading

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 commented 1 year ago

ryanjAA commented 1 year ago

All on 1.14b on FW. :)

junwoo091400 commented 1 year ago

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 :shrug:

MDecarabas commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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

AlexKlimaj commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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). DeepinScreenshot_select-area_20230405144852

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

We are preparing for tests with 1.14.0-beta2 and we experienced the same issues as the ones described by @MDecarabas https://github.com/PX4/PX4-Autopilot/issues/21358#issuecomment-1483580800 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 commented 1 year ago

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: https://github.com/PX4/PX4-Autopilot/issues/20275#issuecomment-1534240970

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 commented 1 year ago

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 commented 1 year ago

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 https://github.com/PX4/PX4-Autopilot/pull/21576 which solves this problem.

kibidev commented 1 year ago

Not tested on real hardware, but I have tested the beta in simulator (standard VTOL), regarding this bug #21327 Logs: https://logs.px4.io/plot_app?log=259ecb46-4352-4de2-b472-ae53ecca7ef2

The bug is included in the 1.14 beta (tested on commit as of commit 18898f1876ec1be9f86d89aedc56b4918c983afa).

junwoo091400 commented 1 year ago

Not tested on real hardware, but I have tested the beta in simulator (standard VTOL), regarding this bug #21327

Thanks for this! I will add this to agenda in maintainers call & raise it to FW/VTOL maintainers!

junwoo091400 commented 1 year ago

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

Thanks a lot! I have addressed the PR 🙏

junwoo091400 commented 1 year ago

Unable to reduce altitude when in mode. Drone will either keep level if sticks are fully down or rise if sticks are centered.

That's odd, I have created an issue to keep track of this separately: https://github.com/PX4/PX4-Autopilot/issues/21627

SPuigUAVW commented 1 year ago

We have been testing the beta, configuring the autopilot for a VTOL. We have the same hardware that we were flying perfectly with 1.12. (Cube Black (FMUv3), i2c Sensirion SDP33)

Pitot sensor calibration is not working. Through the mavlink console, using the sdp3x module, we can see that it does not start automatically and that the i2c bus does not register any address using i2cdetect -b 2. If we start manually with sdp3x start -X, we see that it is running on address 0x21, which is different from the default 33. After this manual start, calibration can be done. If we perform a hardware reset, everything goes back to being uncalibrated and the sdp3x module doesn't start either.

Previously, the parameter SENS_EN_SDP3X had been configured to be activated.

I'm simply raising this information to see if anyone can shed some light or indicate how we can get more information to resolve it.

ryanjAA commented 1 year ago

We have been testing the beta, configuring the autopilot for a VTOL. We have the same hardware that we were flying perfectly with 1.12. (Cube Black (FMUv3), i2c Sensirion SDP33)

Pitot sensor calibration is not working. Through the mavlink console, using the sdp3x module, we can see that it does not start automatically and that the i2c bus does not register any address using i2cdetect -b 2. If we start manually with sdp3x start -X, we see that it is running on address 0x21, which is different from the default 33. After this manual start, calibration can be done. If we perform a hardware reset, everything goes back to being uncalibrated and the sdp3x module doesn't start either.

Previously, the parameter SENS_EN_SDP3X had been configured to be activated.

I'm simply raising this information to see if anyone can shed some light or indicate how we can get more information to resolve it.

Which commit are you on? Link to a log if you have it. I’ve been running sdp33 sensors nonstop for the past few months of testing without issue.

Also, the i2c address is defined by the airspeed board, not px4 side. PX4 side can be altered to register certain addresses as relevant to those specific devices but no changes have been made to the driver so can you confirm your hardware side, etc. Ate you using custom hardware or COTS sdp33 units?

SPuigUAVW commented 1 year ago

We have been testing the beta, configuring the autopilot for a VTOL. We have the same hardware that we were flying perfectly with 1.12. (Cube Black (FMUv3), i2c Sensirion SDP33) Pitot sensor calibration is not working. Through the mavlink console, using the sdp3x module, we can see that it does not start automatically and that the i2c bus does not register any address using i2cdetect -b 2. If we start manually with sdp3x start -X, we see that it is running on address 0x21, which is different from the default 33. After this manual start, calibration can be done. If we perform a hardware reset, everything goes back to being uncalibrated and the sdp3x module doesn't start either. Previously, the parameter SENS_EN_SDP3X had been configured to be activated. I'm simply raising this information to see if anyone can shed some light or indicate how we can get more information to resolve it.

Which commit are you on? Link to a log if you have it. I’ve been running sdp33 sensors nonstop for the past few months of testing without issue.

Also, the i2c address is defined by the airspeed board, not px4 side. PX4 side can be altered to register certain addresses as relevant to those specific devices but no changes have been made to the driver so can you confirm your hardware side, etc. Ate you using custom hardware or COTS sdp33 units?

Thanks for your response. Regarding the commit I just selected in QGC the Beta yesterday and flash it from there. We don't have a log because we where just starting to configure parameters and calibration of the sensors and thats when we encountered the issue. We are using Drotek's SDP33 airspeed sensor (we used it without any problems always).

After some more trying we found that the calibration was not setting SENS_DPRES_OFF parameter, we input it from older parameters back up and the calibration finally saved.

DronecodeBot commented 1 year ago

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-june-06-2023/32473/1

junwoo091400 commented 1 year ago

After some more trying we found that the calibration was not setting SENS_DPRES_OFF parameter, we input it from older parameters back up and the calibration finally saved.

@SPuigUAVW during today's maintainers call, we discussed maybe your calibration value for SENS_DPRES_OFF was getting set to exactly 0.0, for your sensor (and that may cause the code to think that sensor isn't calibrated, because offset of 0.0 implies uncalibrated sensor)

So I had 2 questions for you:

What is the value of that old parameter you set manually?
How did you find out that the SENS_DPRES_OFF was not getting set? Which value did it stay on? (Was it 0.0?)

SPuigUAVW commented 1 year ago

After some more trying we found that the calibration was not setting SENS_DPRES_OFF parameter, we input it from older parameters back up and the calibration finally saved.

@SPuigUAVW during today's maintainers call, we discussed maybe your calibration value for SENS_DPRES_OFF was getting set to exactly 0.0, for your sensor (and that may cause the code to think that sensor isn't calibrated, because offset of 0.0 implies uncalibrated sensor)

So I had 2 questions for you:

What is the value of that old parameter you set manually?

How did you find out that the SENS_DPRES_OFF was not getting set? Which value did it stay on? (Was it 0.0?)

Sorry for my response delay.

We manually set SENS_DPRES_OFF as 0.1. In older backups of firmware 1.11 is set to 0.000000009999999939.
It was 0.00000000... before, we checked it in a saved Parameter backup. We found some info around similar issues in this thread, where my partner VTOLDavid reported problems: https://github.com/PX4/PX4-Autopilot/issues/19088

VTOLDavid commented 1 year ago

Hi, I just found that on 13.3 if you are flying a tailsitter (SITL) on FW in position or hold modes, clicking on the map QGC offers you to go to location or orbit at location . Go to location works as spected but orbit at location surprisingly works and does a orbit with the radius you select, you can set a 5m radius. It goes crazy trying to turn in such a small radius and ignores the parameter NAV_LOITER_RAD.
Log file: https://logs.px4.io/plot_app?log=48c0670b-e030-45cb-a776-9fa25e013cb1

Edit: Same behavior found using 1.14.0.

QGC pictures: https://media.discordapp.net/attachments/1028031026947162143/1116030550810054696/photo_2023-06-07_17-39-42.jpg?width=857&height=586

https://cdn.discordapp.com/attachments/1028031026947162143/1116030551070089226/photo_2023-06-07_17-39-34.jpg

https://cdn.discordapp.com/attachments/1028031026947162143/1116030551304962158/photo_2023-06-07_17-39-20.jpg

AlexKlimaj commented 1 year ago

Just flew my 250 and Rover on 1.14 with my RTCM fixes.

250 https://review.px4.io/plot_app?log=5c742d13-b95e-4df7-91ad-d46d91e50b99 https://review.px4.io/plot_app?log=5c4f81c0-67a4-4566-9c77-b39c946b94fb https://review.px4.io/plot_app?log=15c06091-a431-457b-bec8-f3d9d55c0f1b

Rover with https://github.com/PX4/PX4-Autopilot/pull/21722 https://review.px4.io/plot_app?log=e3a8cb5e-c974-4141-baf5-6bfcd1baa902 https://review.px4.io/plot_app?log=87c6243a-58be-4666-b2b1-5c543ce60129 https://review.px4.io/plot_app?log=bd52a8cc-c2bb-43d1-82d2-aebc11897367 https://review.px4.io/plot_app?log=a1393406-1e01-4daf-a19d-c6b44626c4b2

DusterTheFirst commented 1 year ago

Flew a custom frame, had a lot of normal flights but just this afternoon ran into super weird oscillations. I am unsure of the cause.

https://logs.px4.io/plot_app?log=78b46588-80e0-4a89-bae8-d7a10a51ed82

VTOLDavid commented 1 year ago

Found 2 bugs flying a tailsitter on SITL.

FW loitering with 0 radius:

Disarmed in position mode
Take-off from QGC
When reached selected altitude it changes to hold mode
Transition from QGC
The plane starts turnign with 0 radius.

This also happens if you select in QGC "orbit here" and set a smaller radius than the minimum the airframe can reach. Se discussion on Discord: https://discord.com/channels/1022170275984457759/1116030550742925343

Log: https://logs.px4.io/plot_app?log=d07c73b4-c0f2-4eae-9d21-d4004de7d453

Hold does not stop a Landing command

Flying in hold in FW mode
Hit Land in QGC
Transition to MC and starts descending.
Try to abort the landing selecting hold mode.
Continues descending either in FW or MC mode.

Seems that the altitude setpoint is not set to the current altitude in MC or minimum FW loiter altitude in FW. log: https://logs.px4.io/plot_app?log=c6a6d461-3a02-4d8f-a408-80aaf0711801

DronecodeBot commented 1 year ago

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-june-27-2023/32859/1

junwoo091400 commented 1 year ago

Go to location works as spected but orbit at location surprisingly works and does a orbit with the radius you select, you can set a 5m radius. It goes crazy trying to turn in such a small radius and ignores the parameter NAV_LOITER_RAD.

Thanks for the report @VTOLDavid! I have added this to tomorrow's maintainers meeting notes to discuss

mrpollo commented 1 year ago

Hey @sfuhrer please take a look at the reports above

jstrebel commented 1 year ago

ERROR Mission rejected: Landing waypoint/pattern required. RTL_TYPE 0 has no effect. With 1.13.3, same Mission all OK

SW v1.14.0 (beta) (18898f18) HW: pixhawk4 QGC:4.2.6 log:https://review.px4.io/plot_app?log=a2bd448c-ad95-4b88-a6cf-bafb72a37e3a

DronecodeBot commented 1 year ago

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-june-28-2023/32873/1

sfuhrer commented 1 year ago

ERROR Mission rejected: Landing waypoint/pattern required. RTL_TYPE 0 has no effect. With 1.13.3, same Mission all OK

SW v1.14.0 (beta) (18898f18) HW: pixhawk4 QGC:4.2.6 log:https://review.px4.io/plot_app?log=a2bd448c-ad95-4b88-a6cf-bafb72a37e3a

You can customize requiring takeoff/landings in missions through MIS_TKO_LAND_REQ, see also https://docs.px4.io/main/en/flight_modes/mission.html#mission-feasibility-checks.

sfuhrer commented 1 year ago

Found 2 bugs flying a tailsitter on SITL.

hi @VTOLDavid , I see that the PX4 version you used is 1.13, after this PR. Can you check if the same happens on v1.14? I briefly checked in SITL and could not reproduce neither of your reported two issues.

VTOLDavid commented 1 year ago

Found 2 bugs flying a tailsitter on SITL.

hi @VTOLDavid , I see that the PX4 version you used is 1.13, after this PR. Can you check if the same happens on v1.14? I briefly checked in SITL and could not reproduce neither of your reported two issues.

Yes it was in 1.13.3, latest stable version. I will check it in 1.14. I am testing both versions and though I was in 1.14.

VTOLDavid commented 1 year ago

Not happening in 1.14

junwoo091400 commented 1 year ago

After some more trying we found that the calibration was not setting SENS_DPRES_OFF parameter, we input it from older parameters back up and the calibration finally saved.

As I noted in https://github.com/PX4/PX4-Autopilot/issues/19088#issuecomment-1613285885, the airspeed calibration itself should work in v1.14 beta, however as you stated, if the SENS_DPRES_OFF is indeed not getting saved, could you provide more information on how the calibration went?

Did the airspeed calibration indeed finish? What did the QGC calibration screen show?

mwshafer commented 1 year ago

@mrpollo I’ve been testing with 1.14 beta for some time now and have been continually dealing with high vibration levels. I’ve only recently realized that this is a PX4 specific issue, as I loaded Arducopter today and the vibration levels all looked fine for that flight. This morning I completed two back to back flights with my system which runs a Cube Orange+. The first flight is with PX4 and the second was with Arducopter. Both log files can be found here. The PX4 flight was posted in Flight Review here: https://review.px4.io/plot_app?log=a9bebd55-10d4-42df-b12b-5781106c4696

The PX4 flight had a terrible oscillation during the descent on RTL that nearly crashed the drone. I was able to recover thankfully.

What is really odd is that the first two IMUs, which are supposed to be mechanically isolated/damped are showing higher vibration levels than the one that is hard mounted in the board:

bokeh_plot 1

I’ve posted this issue here as well: https://discuss.px4.io/t/accel-1-clipping-with-px4-no-problems-with-arducopter/32247/4

DronecodeBot commented 1 year ago

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/high-vibration-in-cube-orange/32194/3

AlexKlimaj commented 1 year ago

release/1.14 with #21789 #21769 #21019

https://review.px4.io/plot_app?log=a1d5cbbb-fe78-425b-9ef6-c99dca2d6139 https://review.px4.io/plot_app?log=f458c74a-898b-4e03-b1e4-50315a1ec2b1 https://review.px4.io/plot_app?log=622f14ec-ec4e-4d45-97cb-475798fb1f84

jstrebel commented 1 year ago

Fixed Wing FX61 using current 1.14main (QGC 4.2.6) Fairly good without tuning. (setting MIS_TKO_LAND_REQ as recommended by sfuhrer) https://review.px4.io/plot_app?log=b9f996e3-43ed-42b2-ad12-5f67942e72c5

mwshafer commented 1 year ago

I just tried to install the beta version and I am getting this error:

I have tried this multiple times on both Mac and Windows, all with the same result. I’m using the daily build of QGC. This worked last week when I installed 1.14 beta.

I then tried to build it manually and this is what I am getting:

dasl@dasl-virtual-machine:~/repos/PX4-Autopilot$ git branch
* beta
  main
dasl@dasl-virtual-machine:~/repos/PX4-Autopilot$ git pull
Already up to date.
dasl@dasl-virtual-machine:~/repos/PX4-Autopilot$ make cubepilot_cubeorangeplus
[1/606] Generating nuttx/drivers/libdrivers.a
FAILED: NuttX/nuttx/drivers/libdrivers.a /home/dasl/repos/PX4-Autopilot/build/cubepilot_cubeorangeplus_default/NuttX/nuttx/drivers/libdrivers.a 
cd /home/dasl/repos/PX4-Autopilot/platforms/nuttx/NuttX/nuttx && /usr/bin/cmake -E remove -f /home/dasl/repos/PX4-Autopilot/platforms/nuttx/NuttX/nuttx/drivers/libdrivers.a && find drivers -type f -name *.o -delete && make -C drivers --no-print-directory --silent all TOPDIR="/home/dasl/repos/PX4-Autopilot/platforms/nuttx/NuttX/nuttx" KERNEL=y EXTRAFLAGS=-D__KERNEL__ && /usr/bin/cmake -E copy_if_different /home/dasl/repos/PX4-Autopilot/platforms/nuttx/NuttX/nuttx/drivers/libdrivers.a /home/dasl/repos/PX4-Autopilot/build/cubepilot_cubeorangeplus_default/NuttX/nuttx/drivers/libdrivers.a
mtd/ramtron.c: In function 'ramtron_readid':
mtd/ramtron.c:72:39: error: 'CONFIG_RAMTRON_EMULATE_SECTOR_SHIFT' undeclared (first use in this function); did you mean 'RAMTRON_EMULATE_SECTOR_SHIFT'?
   72 | #define RAMTRON_EMULATE_SECTOR_SHIFT  CONFIG_RAMTRON_EMULATE_SECTOR_SHIFT
      |                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mtd/ramtron.c:72:39: note: in definition of macro 'RAMTRON_EMULATE_SECTOR_SHIFT'
   72 | #define RAMTRON_EMULATE_SECTOR_SHIFT  CONFIG_RAMTRON_EMULATE_SECTOR_SHIFT
      |                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mtd/ramtron.c:72:39: note: each undeclared identifier is reported only once for each function it appears in
   72 | #define RAMTRON_EMULATE_SECTOR_SHIFT  CONFIG_RAMTRON_EMULATE_SECTOR_SHIFT
      |                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mtd/ramtron.c:72:39: note: in definition of macro 'RAMTRON_EMULATE_SECTOR_SHIFT'
   72 | #define RAMTRON_EMULATE_SECTOR_SHIFT  CONFIG_RAMTRON_EMULATE_SECTOR_SHIFT
      |                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mtd/ramtron.c:73:39: error: 'CONFIG_RAMTRON_EMULATE_PAGE_SHIFT' undeclared (first use in this function); did you mean 'RAMTRON_EMULATE_PAGE_SHIFT'?
   73 | #define RAMTRON_EMULATE_PAGE_SHIFT    CONFIG_RAMTRON_EMULATE_PAGE_SHIFT
      |                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mtd/ramtron.c:73:39: note: in definition of macro 'RAMTRON_EMULATE_PAGE_SHIFT'
   73 | #define RAMTRON_EMULATE_PAGE_SHIFT    CONFIG_RAMTRON_EMULATE_PAGE_SHIFT
      |                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[1]: *** [Makefile:92: ramtron.o] Error 1
[2/606] Generating nuttx/arch/arm/src/libarch.a
FAILED: NuttX/nuttx/arch/arm/src/libarch.a /home/dasl/repos/PX4-Autopilot/build/cubepilot_cubeorangeplus_default/NuttX/nuttx/arch/arm/src/libarch.a 
cd /home/dasl/repos/PX4-Autopilot/platforms/nuttx/NuttX/nuttx && /usr/bin/cmake -E remove -f /home/dasl/repos/PX4-Autopilot/platforms/nuttx/NuttX/nuttx/arch/arm/src/libarch.a && find arch/arm/src -type f -name *.o -delete && make -C arch/arm/src --no-print-directory --silent all TOPDIR="/home/dasl/repos/PX4-Autopilot/platforms/nuttx/NuttX/nuttx" KERNEL=y EXTRAFLAGS=-D__KERNEL__ && /usr/bin/cmake -E copy_if_different /home/dasl/repos/PX4-Autopilot/platforms/nuttx/NuttX/nuttx/arch/arm/src/libarch.a /home/dasl/repos/PX4-Autopilot/build/cubepilot_cubeorangeplus_default/NuttX/nuttx/arch/arm/src/libarch.a
chip/stm32_sdmmc.c:592:41: error: 'GPIO_SDMMC1_D0' undeclared here (not in a function); did you mean 'GPIO_SDMMC1_D5_0'?
  592 |   .d0_gpio           = SDMMC1_SDIO_PULL(GPIO_SDMMC1_D0),
      |                                         ^~~~~~~~~~~~~~
chip/stm32_sdmmc.c:154:35: note: in definition of macro 'SDMMC1_SDIO_PULL'
  154 | #  define SDMMC1_SDIO_PULL(g)  (((g) & ~GPIO_PUPD_MASK) | GPIO_PULLUP)
      |                                   ^
chip/stm32_sdmmc.c: In function 'sdio_initialize':
chip/stm32_sdmmc.c:3487:41: error: 'GPIO_SDMMC1_D1' undeclared (first use in this function); did you mean 'GPIO_SDMMC1_D1_0'?
 3487 |       stm32_configgpio(SDMMC1_SDIO_PULL(GPIO_SDMMC1_D1));
      |                                         ^~~~~~~~~~~~~~
chip/stm32_sdmmc.c:154:35: note: in definition of macro 'SDMMC1_SDIO_PULL'
  154 | #  define SDMMC1_SDIO_PULL(g)  (((g) & ~GPIO_PUPD_MASK) | GPIO_PULLUP)
      |                                   ^
chip/stm32_sdmmc.c:3487:41: note: each undeclared identifier is reported only once for each function it appears in
 3487 |       stm32_configgpio(SDMMC1_SDIO_PULL(GPIO_SDMMC1_D1));
      |                                         ^~~~~~~~~~~~~~
chip/stm32_sdmmc.c:154:35: note: in definition of macro 'SDMMC1_SDIO_PULL'
  154 | #  define SDMMC1_SDIO_PULL(g)  (((g) & ~GPIO_PUPD_MASK) | GPIO_PULLUP)
      |                                   ^
chip/stm32_sdmmc.c:3488:41: error: 'GPIO_SDMMC1_D2' undeclared (first use in this function); did you mean 'GPIO_SDMMC1_D2_0'?
 3488 |       stm32_configgpio(SDMMC1_SDIO_PULL(GPIO_SDMMC1_D2));
      |                                         ^~~~~~~~~~~~~~
chip/stm32_sdmmc.c:154:35: note: in definition of macro 'SDMMC1_SDIO_PULL'
  154 | #  define SDMMC1_SDIO_PULL(g)  (((g) & ~GPIO_PUPD_MASK) | GPIO_PULLUP)
      |                                   ^
chip/stm32_sdmmc.c:3489:41: error: 'GPIO_SDMMC1_D3' undeclared (first use in this function); did you mean 'GPIO_SDMMC1_D3_0'?
 3489 |       stm32_configgpio(SDMMC1_SDIO_PULL(GPIO_SDMMC1_D3));
      |                                         ^~~~~~~~~~~~~~
chip/stm32_sdmmc.c:154:35: note: in definition of macro 'SDMMC1_SDIO_PULL'
  154 | #  define SDMMC1_SDIO_PULL(g)  (((g) & ~GPIO_PUPD_MASK) | GPIO_PULLUP)
      |                                   ^
chip/stm32_sdmmc.c:3491:24: error: 'GPIO_SDMMC1_CK' undeclared (first use in this function); did you mean 'GPIO_SDMMC1_CK_0'?
 3491 |       stm32_configgpio(GPIO_SDMMC1_CK);
      |                        ^~~~~~~~~~~~~~
      |                        GPIO_SDMMC1_CK_0
chip/stm32_sdmmc.c:3492:41: error: 'GPIO_SDMMC1_CMD' undeclared (first use in this function); did you mean 'GPIO_SDMMC1_CMD_0'?
 3492 |       stm32_configgpio(SDMMC1_SDIO_PULL(GPIO_SDMMC1_CMD));
      |                                         ^~~~~~~~~~~~~~~
chip/stm32_sdmmc.c:154:35: note: in definition of macro 'SDMMC1_SDIO_PULL'
  154 | #  define SDMMC1_SDIO_PULL(g)  (((g) & ~GPIO_PUPD_MASK) | GPIO_PULLUP)
      |                                   ^
make[1]: *** [Makefile:132: stm32_sdmmc.o] Error 1
ninja: build stopped: subcommand failed.
make: *** [Makefile:232: cubepilot_cubeorangeplus] Error 1

junwoo091400 commented 1 year ago

I’m using the daily build of QGC. This worked last week when I installed 1.14 beta.

Weird, since the beta target shouldn't have been available at all, according to the last beta S3 bucket Jenkins log: http://ci.px4.io/blue/organizations/jenkins/PX4_misc%252FFirmware_s3_deploy_beta/detail/Firmware_s3_deploy_beta/47/pipeline/

Also, I don't have the same make error when I build the target in release/1.14 branch. For now, could you download the binary from the main branch NuttX build artifacts from runs like this one? -> https://github.com/PX4/PX4-Autopilot/actions/runs/5510817520

PX4 / PX4-Autopilot