Community Announcement
Community Q&A
Project Updates
General Discussions
Weekly Overview
High priority queue
Release
Last FW/VTOL Meeting
@tstastny will make PR this week-ish
all agreed best to use path following through flare, add slip controller later
@Jaeyoung-Lim )
@Jaeyoung-Lim made a first list here: Simulation Survey - Google Docs
@ryanjAA will add more info on research sim
@sfuhrer tried in SITL, could not reprodu…
Specify what you are trying to achieve
Specify what environment / platform you are using
Prepare a Link or Document to help understand if possible
First, ask the question on the Slack or create a Github Issue !
If you take over 5 minutes for the question, please continue in Slack or a Github Issue.
The issue is that old gimbal commands are not imported in MAVSDK 0.33.0 Mission import.
@JulianOes With newer MAVSDK versions the import has moved to the MissionRaw plugin which allows to import any sort of missions, and that should fix it. Updating MAVSDK should not be an issue as it tries to be mostly backwards compatible.
@junwoo0914
mavlink:master ← junwoo091400:pr_component_metadata_frames_support
opened 02:36PM - 01 Nov 22 UTC
## About
This is a MAVLink part for the Airframe selection improvement project … I have been working on for the last 2 weeks.
Frame metadata is meant to serve as a definite reference that can be dynamically fetched by the GCS (as done with all other component metadata), to show the frames that are actually supported.
Additionally, the frame JSON schema is defined in a way where we can structure the frames within another frame in a cascaded fashion, which enables a User-Interface workflow that wasn't possible before, which is a JSON- defined Frame selection workflow.
This is best demonstrated by the GIF below.
### Notes
For now, the JSON Schema & Examples were fetched from [this commit](https://github.com/junwoo091400/PX4-Airframe-Metadata-support/commit/75d54c40dd234959ab284604fc6c3942c909ef09) in my Qt UI repository.
This is what will eventually happen to [this](https://github.com/mavlink/qgroundcontrol/pull/10343) too I hope, as having MAVLink defined schema would make it easier for different Autopilots to agree on the format used by the QGC / Mission Planner.
### Frames metadata example
As included as part of the PR, the Frames JSON file would look something like this:
```json
{
"version": 1,
"settings": {
"frame_id_parameter": "SYS_AUTOSTART"
},
"frames_v1": [
{
"name": "multicopter",
"type": "group",
"description": "Rotary vehicles with multiple rotors to lift it's body",
"image": "Multirotor",
"subgroups": [
{
"name": "generic multicopter",
"type": "frame",
"description": "Generic multicopter with customizable number of rotors",
"image": "",
"frame_id": 1300
},
{
"name": "quadcopter",
"type": "group",
"description": "Multicopters with 4 rotors",
"image": "Quadrotor",
"subgroups": [
{
"name": "Holybro X500 v2",
"type": "frame",
"description": "Holybro's X500 V2 frame kit",
"manufacturer": "Holybro",
"image-custom": "holybro_x500_v2",
"url": "http://www.holybro.com/product/x500-v2-kit/",
"frame_id": 1313
}
]
},
{
"name": "hexacopter",
"type": "group",
"description": "Multicopters with 6 rotors",
"image": "Hexarotor",
"subgroups": [
{
"name": "Yuneec H520E Hexacopter",
"type": "frame",
"description": "Yuneec H520E Hexacopter with a camera & landing gear",
"manufacturer": "Yuneec",
"image-custom": "yuneec_h520e",
"url": "https://www.conrad.ch/de/p/yuneec-h520e-speccombo-hexacopter-rtf-profi-kameraflug-mit-waermebild-orange-schwarz-2450997.html",
"frame_id": 1254
},
{
"name": "Vector Hexacopter 2.2",
"type": "frame",
"description": "Yuneec H520E Hexacopter with a camera & landing gear",
"manufacturer": "Vision Aerial",
"image-custom": "vision_vector_hexacopter",
"url": "https://visionaerial.com/product/vector-hexacopter/",
"frame_id": 1532
}
]
}
]
}
]
}
```
### Final GCS outcome demo
This is from the [Qt application repository](https://github.com/junwoo091400/PX4-Airframe-Metadata-support#px4-frame-metadata-support-test-repository) linked below.
### Resources
- You can check out the progress / details of this project in the document here: https://docs.google.com/document/d/1wpGDQyJLv3AHAqMH-vxWuZ1HYksX7oq_vldEXCbxmPI/edit#
- This is a standalone Qt application that implements the Visualization / parsing of the Frames metadata, which will get ported over to QGC: https://github.com/junwoo091400/PX4-Airframe-Metadata-support
## Contents
- Added JSON schema and example file for the Frames componenet metadata
## Description
- This adds a new metadata type 'Frames' for supporting dynamically loading the supported frames from the Autopilot to the GCS
- Frame is a generic term for a previously used term `Airframe`, to inclusively bundle ground vehicle / boat / etc, not just aerial vehicles
- The Frame JSON structure is recursive, and any frame can contain many other frames in it's sub-group, which also defines the GCS user selection workflow (Starting from high level, down to low level)
- Schema also needs to be updated whenever there's a new type of a vehicle that we need to add an image for, in order to have a valid `image` Enumerator string tag
- The frames are in a list, to make sure we preserve the order, in order to deliver a consistent GCS usage experience
## TODOs
- [x] Create QGC Implementation for supporting Frames metadata: https://github.com/mavlink/qgroundcontrol/pull/10472
mavlink:master ← junwoo091400:pr_frames_metadata_support
opened 04:38PM - 01 Nov 22 UTC
## Description
This is the QGC implementation of https://github.com/mavlink/mav… link/pull/1908
It will eventually look something like this in QGC:
### What will be implemented
1. Support for Frames component metadata
2. New metadata based Frames visualization page (Fallback to old Frames page, if metadata isn't supported by the target)
## TODOs
- [x] Initial crude porting of the files from the [standalone Qt application](https://github.com/junwoo091400/PX4-Airframe-Metadata-support/commit/75d54c40dd234959ab284604fc6c3942c909ef09)
- [x] Refactor to expose the new Frames page in QML in the Airframes tab, and rename the tab to `Frames` :stuck_out_tongue:
- [x] Implement (temporary) way to visualize the `frames.example.json` from the MAVLink PR, to test functionality
- [ ] Iterate on the UI design, to make it more intuitive (maybe Animation)
- [ ] Implement Component Metadata fetching part from the Autopilot
- [ ] Implement Component Metadata generation in PX4 (To be updated)
- [ ] Test the whole system in action with a PX4 target containing the new Frames metadata!
Why can’t we use a Control allocation better? << Effort worth spent
Then we can remove the dependency to the image assets.
We can transform the concept of an ‘Airframe’ as a helper for specifying Control Allocation parameters
Ideally: We will have everything defined in the control allocation.
What will be an Airframe be in the future: Not just a like a script.
David: If we don’t have an access to the GCS, how are you supposed to run different setups? (E.g. setting PWM configs).
Had to debug something, and bringing back the params
Right now it is not possible to export (backup) a param & load it back in via the Console interface.
Hi, I have a question about the MC rate controller. I’ve noticed that PX4 differs here from other firmwares in that PX4 uses the rate setpoint with the feed forward term while other firmwares (betaflight etc) use the derivative of the rate setpoint.
What is the reason for using the actual setpoint and are there any benefits of using either?
The feed forward is multiplied with the setpoint instead of the derivative of the setpoin t. This way you cannot tune the feed forward in a meaningful way. The feed forward should cause the requested change of angular rate, not give a constant output proportional to the requested rate.
Currently the FF term only account for the damping.
Discord message link
Action Item: Address the proposal of a new structure multicopter rate control in discord (With block diagrams!
opened 05:03PM - 21 Sep 22 UTC
closed 08:44AM - 09 May 23 UTC
Multirotor 🛸
priority-critical
bug-report
release blocker ❗️
On recent main, occasionally I will get 100% thrust from the position controller… .
This is with multiple baros and a rangefinder.
Took off in position mode, then it went full thrust.
https://review.px4.io/plot_app?log=f0acb7d2-7d1e-4ec9-92ca-0a816fd131f8
I was trying to land, sitting on the ground waiting for it to disarm. It wouldn't disarm so I throttled back up a bit to try again and it went 100% thrust.
https://review.px4.io/plot_app?log=10ece277-09e1-4e67-be8e-ca7b87b7555e
Integrator seems to be causing the takeoff behavior
Seems to happen when the hoverThrust gets set
committed 02:42PM - 08 Jan 22 UTC
The integrator now absorbs properly the change in hover thrust
PX4:main ← PX4:pr-nuttx_10.3_upgrade
@dagar - v5 stack check is now running
With this fix, the Cannode of Alex started working. Would be nice to have more Cannode developers testing on it.
Output of ver all inside the NSH, NuttX tag is wrongly displayed.
opened 12:26PM - 28 Oct 22 UTC
closed 09:49AM - 20 Oct 23 UTC
Fixed Wing 🛩️
Offboard
bug-report
## Describe the bug
While flying in offboard mode, preflight errors keep appear… ing
## To Reproduce
Steps to reproduce the behavior:
1. Fly in offboard mode, for a while in SITL
2. Check px4 shell
## Expected behavior
Preflight errors should not prompt after takeoff
## Log Files and Screenshots
- Flight log(Could not upload to flight review due to size): https://drive.google.com/file/d/11N-AGdYJllGIyIddgSK6Ry6q_e2JtuPd/view?usp=sharing
```
[ERROR] [1666958082.411005289, 101.460000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666958133.011041949, 152.040000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666958183.610969284, 202.620000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666958234.210952414, 253.200000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666958284.811088021, 303.776000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666958335.410965193, 354.356000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666958386.011019053, 404.936000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666958436.611025057, 455.516000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666958487.210986083, 506.092000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666958537.810985559, 556.672000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666958588.411034201, 607.252000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666958639.010983934, 657.832000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666958689.611000868, 708.408000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666958740.210998311, 758.988000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666958790.810989592, 809.564000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666958841.410952192, 860.144000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666958892.010979900, 910.724000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666958942.611082432, 961.304000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666958993.211071045, 1011.880000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666959043.810952042, 1062.460000000]: TM : Time jump detected. Resetting time synchroniser.
[ERROR] [1666959094.410951561, 1113.036000000]: TM : Time jump detected. Resetting time synchroniser.
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
[ERROR] [1666959145.011004882, 1163.612000000]: TM : Time jump detected. Resetting time synchroniser.
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
[ERROR] [1666959195.610966178, 1214.192000000]: TM : Time jump detected. Resetting time synchroniser.
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: Yaw estimate error
WARN [health_and_arming_checks] Preflight Fail: velocity estimate error
WARN [health_and_arming_checks] Preflight Fail: velocity estimate error
```
## Drone (please complete the following information):
- SITL Gazebo `plane` model
## Additional context
Add any other context about the problem here.
Probably a regression that are getting checked during the flight.
This should have fixed it?
“Do I need to be concerned?”
We need to capture the context of internal/mag, and handle that in estimator well, to reduce these errors. Most of the internal mags are just good enough to fly & complains.
Recently updated Issues / PRs in PX4-Autopilot Link
Pull Requests
PX4:main ← dirksavage88:lightware_sf45
opened 03:42PM - 08 Jul 22 UTC
Lightware SF45/B rotating distance sensor driver that publishes distance and yaw… angle (through the obstacle distance sensor message). Preliminary testing I show the sensor is able to detect obstacles:
I am able to publish to obstacle distance msg and I see valid distance values moving through the bins. It is also stopping before collision with an obstacle if within CP distance defined in the parameters (tested using 3m).
Ardupilot has a working driver that can be used as a reference [here](https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_Proximity/AP_Proximity_LightWareSF45B.cpp)
Additionally, Lightware has a sample cpp library on their github.
Serial driver defaults to TEL1 due to the power requirements of the sensor which is documented [here](http://support.lightware.co.za/sf45b/#/pixhawk) It is possible to change this default for newer boards that have other uarts that satisfy the power requirements, this can be done through SENS_EN_SF45 parameter. Baud rate is set to 115200.
Update rate defaults to 50hz, but I have tested at higher rates. This can be set by parameter.
Orientation (upright or upside down mounting) parameter is available, will have to verify the yaw corrections for the upside down mounting is correct. There is also a yaw configuration parameter that allows user to have sensor face in a different direction other than default forward facing.
An I2C driver can be implemented but does not permit continuous streaming of distance data.
The lightware sf45 can be configured in the Lightware Studio [software](https://lightwarelidar.com/pages/lightware-studio) to set the Baud rate before connecting to Pixhawk, additionally the scan angle can be changed for the largest field of view possible: 0-160 and -160 to 0
Future considerations: Parameters to map sectors around the airframe to ignore (e.g. gps mast).
@dagar I can send you the sensor if you would like your own to test.
@davids5 the serial port local options appear to work, let me know if it needs refinement or extra comments to explain the serial options configuration
INA220 driver
PX4:main ← benjinne:pr-add-ina220-driver
opened 01:42PM - 28 Oct 22 UTC
## Describe problem solved by this pull request
Adds the INA220 driver
## De… scribe your solution
based on the INA226 driver
## Test data / coverage
Tested using an ina220 and validated current voltage readings were accurate compared to multi-meter
Cannode PWM support - Alex
PX4:main ← AlexKlimaj:pr-cannode-pwm
opened 08:03PM - 30 May 22 UTC
This PR adds initial support for Cannode PWM adapters such as the ARK CANnode.
…
https://arkelectron.com/product/ark-cannode/
All the basic pieces are in place. The individual PWM_MAIN params on the node need to be setup for the desired PWM output behavior. FUNC as well as MIN, MAX, DISARM, etc.
Then using the control allocator on the flight controller, setup the motor/servo outputs to use UAVCAN. One caveat is that COM_PREARM_MODE needs to be set on the flight controller for the actuator test to work through QGC to the cannode output.
UAVCAN_PUB_ARM on the flight controller needs to be enabled for the cannode outputs to work.
dshot is running but does not appear to work.
https://review.px4.io/plot_app?log=f89c1a70-f969-4493-adf8-86f1715dcd55
Issues
PX4 Dev Call: October 26, 2022
Discussion based on: High-Priority Queue · GitHub
Community Announcement
Community Q&A (No deep technical discussions)
Guideline for asking a Question
Project Updates
General Discussions
) - Sander
Weekly Overview
Github
Slack
Last Dev-Call
Release