rroche
March 16, 2022, 5:01pm
1
March 23, 2022
Join us
Agenda
Community Q&A
Project Updates
High priority queue
Release
In-Depth discussions
Moderation
After 5 seconds of silence, move onto the next topic
Community Q&A : Maximum 3 - 5 min limit for each question . If the discussion isn’t finished, ask the Questioner to create a Github Issue about it and continue discussion there.
Limit discussions to maximum 5 min , then it should be continued in In-Depth discussions.
Community Announcement
PX4 Dev Summit 2022 is back in Austin Texas!
Timeline:
CFP Open: March 18th (Today!)
CFP Closes: April 19th
CFP Notifications: Week of May 2nd
Schedule Announcement: Week of May 9th
Presentation Slide Due Date: June 13th
Event Dates: Thursday, June 23rd - Friday, June 24th, 2022
Since we are back in person, we are pushing for increased content diversity, and we welcome any of the below:
Session Presentation: 30-min
Panel Discussions: 30-min
Birds of a Feather: 45/60-min
Lightning Talk: 5/15-min
Workshop: 1.5/2-hours
Apply to the CFP directly on our Website
Community Q&A
Raise your questions!
Tests
PX4:master
← PX4:pr-fix-ci
opened 01:56PM - 23 Mar 22 UTC
@dagar - I imagine the whole test could be removed if it is tested on any CM4
PX4:master
← PX4:pr-v6x-rev3-sensors
opened 06:20PM - 11 Mar 22 UTC
Added Sensor Set 3
![image](https://user-images.githubusercontent.com/194582… 1/157926965-76d925df-9848-4892-8287-3cda33b7023a.png)
Holybro sensor set
Holybro : F7 / H7 few available in stock, 100 pin version in stock
QGC Taking over USB
opened 10:50PM - 10 Mar 22 UTC
Report: Bug
## Expected Behavior
If there is not a CommLink automatically configured to use… a serial device, nor a box selected under General settings to automatically connect via `Pixhawk`, then that serial device should never be opened by QGC.
## Current Behavior
- Opened QGC with two serial interfaces connected on host device:
- /dev/ttyUSB0 (USB serial adapter being used to monitor PX4 debug output on console pins via `picocom`)
- /dev/ttyACM0 (USB connection to FMU intended for use by QGC
- QGC opened /dev/ttyUSB0 despite all auto connections being unchecked and no comm links specified for it (there was one specified for manual, non-auto connection to /dev/ttyACM0
- Garbage starts spewing out of the console, almost as if the flight controller has been reconfigured for a different baud rate by QGC
- Upon trying to close and re-open picocom, I am informed `Device or resource busy` as /dev/ttyUSB0 is being held by QGC
- Close QGC
- Re-open picocom and the device is available and comms are back to normal
## Steps to Reproduce:
Steps are provided above, but the strangest thing is that the behavior appears to be random. Sometimes it happens, sometimes it doesn't.
Out of 10 tries, 7 didn't cause the issue and 3 did.
## System Information
When posting bug reports, include the following information
- Operating System: Ubuntu 20.04
- QGC Version: 4.2.0
- QGC build: Daily AppImage from a few weeks/months ago
- Flight Controller: Matek H743 Wing v1
- Autopilot (with version): PX4 master
Same behavior, suspected bug. Platform on Ubuntu
Project Updates
Updates from the team
Follow Target project
PX4:potaito/new-follow-me-task
← junwoo091400:followme_refactor
opened 03:08PM - 25 Feb 22 UTC
**Describe problem solved by this pull request**
Refer to the document : https:… //docs.google.com/document/d/1E04Rn6sxYNqKve4-KZYdC2-9LExKmHKuYjWZlwf61rA/edit
**Describe your solution**
**Describe possible alternatives**
A clear and concise description of alternative solutions or features you've considered.
**Test data / coverage**
This change log : https://logs.px4.io/plot_app?log=6561ce69-e2e3-46c3-9e13-e29f2dbc11c7
Alessandro PR log : https://logs.px4.io/plot_app?log=fa76985d-87c6-4c4f-9164-fa2f2c15338b
**Additional context**
* This PR is to be merged to a pre-existing PR : #18026
* Depends on library added from #19246 and #19249.
* Proposal brainstorming issue : #19251
* User Doc Update PR : https://github.com/PX4/PX4-user_guide/pull/1810
* Scripts I used for testing the algorithm : https://github.com/junwoo091400/Follow-Target-Algorithm-Scripts
* Script used to test Follow-Me in SITL : https://github.com/junwoo091400/PX4-Followme-Sim-Script
* Visualizer script that was used for drone's orbit angle set-point overshooting problem : https://github.com/junwoo091400/Follow-Target-uLog-Visualizer
### Discussions
1. Should we just change the 'follow perspective' into a single number parameter (0 ~ 360 degrees), instead of using an enum / selection of : "Front, Back, Right, Left, etc."?
2. Google Astyle for the member variables : Do we need to add the _ suffix?
### TODOS
- [x] Reduce follow_target_status logging rate to 200ms interval or 400ms
- [x] MAVSDK Param update
- https://github.com/mavlink/MAVSDK-Proto/pull/287
- https://github.com/mavlink/MAVSDK/pull/1770
- [ ] Later on implement the Multcopter Rate Controller not directly applying acceleration setpoint -> Issue at #19543
- [ ] Maybe move onto [YAML based](https://docs.px4.io/master/en/advanced/parameters_and_configurations.html#parameter-metadata) Parameter definitions?
- [ ] Add the Leash mode (as if drone was hovering and the user was connected to the drone, so it would follow around like as if it was leashed)
- [ ] Add fixed orbit angle mode (staying always on the north side, etc. No orbit angle transitions)
- [ ] [Check if I get a more stable yaw setpoint if I use the heading from the position setpoint to the target estimate, instead of the real position.](https://github.com/PX4/PX4-Autopilot/pull/19260#discussion_r869034921)
In the review process & addressing comments
Sign function fix
PX4:master
← PX4:sign-function
opened 03:51PM - 21 Mar 22 UTC
**Describe problem solved by this pull request**
Fixes #19361 thanks to @tstast… ny !
- The sign function has no documentation
- There are no unit tests for the sign function
- The sign function has a bug where unexpectedly sign(0) = -1 and sign(FLT_EPSILON) = 0
**Describe your solution**
Add documentation and unit tests.
For the bug, I'm really not sure why the putative deadzone was added here: https://github.com/PX4/PX4-Autopilot/pull/12905/files#diff-b76fc4ece0dac2e83a0e972fbea85372175487ed12f9146ee211252e51da3494R51
It never worked before. It would need to be `(T(FLT_EPSILON) < val) - (val < -T(FLT_EPSILON))`.
**Describe possible alternatives**
We could add another sign function that has a configurable deadzone with a default parameter value if there's the need. Also we should move it back to the PX4 math::Functions.
**Test data / coverage**
New unit tests.
**Additional context**
- The sign function was added in https://github.com/PX4/PX4-Autopilot/pull/6638/files#diff-9c4d6427fcd835e10b4d068f53389a16801aac8628578944e0e88b8747e2798fR50
- used for quaternion conjugation corner cases in https://github.com/PX4/PX4-Autopilot/commit/e81483a808ce7b0217c11d3dc0fce90685f44353#diff-1de2137691523f51e9a4a2a3f5fdaed75974729fd912cda6f0612bab751d3993R82
- duplicate in PX4 math removed in https://github.com/PX4/PX4-Autopilot/pull/14374/files#diff-b76fc4ece0dac2e83a0e972fbea85372175487ed12f9146ee211252e51da3494L49
Orbit mode PRs
PX4:master
← PX4:orbit-tangential-stick-input-upstream
opened 05:55PM - 21 Mar 22 UTC
**Describe problem solved by this pull request**
When flying an orbit with the … yaw behavior `ORBIT_YAW_BEHAVIOUR_HOLD_FRONT_TANGENT_TO_CIRCLE` where the vehicle is facing tangential to the circle and hence facing the direction of travel it's unintuitive to change the radius and velocity of the orbit with the usual stick mapping. This is because usually the stick input is mapped in the body yaw frame.
**Describe your solution**
I changed the stick input to also act 90° offset compared to when flying with the vehicle facing the center of the circle. Such that's intuitively in body yaw frame.
Doing that I found the direction of where the vehicle is facing and hence also how the stick input is mapped would change 180° when switching rotation direction. This makes direction switches by stick unusable. To work around the problem I made the vehicle go backward when the rotation direction is switched by stick input.
**Test data / coverage**
This was tested in SITL and on a real vehicle that mostly uses `ORBIT_YAW_BEHAVIOUR_HOLD_FRONT_TANGENT_TO_CIRCLE`.
PX4:master
← PX4:orbit-radius-limit
opened 10:09AM - 21 Mar 22 UTC
**Describe problem solved by this pull request**
For certain use cases the limi… t is just too low and if the limit is exceeded currently there a bug where the radius is just pruned instead of not executing the out of range orbit command.
Note: Not rejecting out of range radiuses is a regression:
https://github.com/PX4/PX4-Autopilot/commit/9bd46be1242535d5ec3da04c11d274aa22a2f805#diff-89127f427c1fc4e2fb02b97822ec75dc1bc7a4690ae4cd3aba8bc4f811250717L61
**Describe your solution**
- > the orbit radius is limited to 100m. If flying in open areas this limit is too strict.
Makes it configurable by parameter. I'm open to suggestions for the default.
- > When commanding a larger radius in AMC, it gets resized to 100m.
Fixes the bug by not acknowledging the command and stopping instead of executing the Orbit.
This is already better than just changing the radius and then starting to execute but it should be further improved with e.g. an error message and possibly by switching mode.
**Test data / coverage**
SITL testing with out-of-range radiuses and hitting the limit by stick input.
High priority queue
Discussion based on board: https://github.com/orgs/PX4/projects/24
Release
In-Depth discussions
For smaller groups expanding technical discussions, stay until the end and follow up.
CI Discussion
PX4:main
← PX4:pr-containers
opened 09:32PM - 16 Dec 21 UTC
Initial work to have one container for CI and Development within tree
In orde… r to build you have to be at the top of the firmware directory and run:
```
./Tools/docker_run.sh make all_variants_px4_fmu-v5x
```
Thanks to @julianoes for the great work on https://github.com/PX4/PX4-containers/pull/288 I based this PR on his work
Stick scaling discussion
PX4:master
← junwoo091400:pr_sticks_verbose_functions
opened 04:14PM - 10 Mar 22 UTC
**Describe problem solved by this pull request**
'Sticks' utility library is us… ed by Flight Tasks. While implementing a Follow-Target feature (#19260) with RC-controllable behavior, I found that **it is unclear as to which 'user input' each input vector corresponds to.**
**Describe your solution**
Added functions each returning user input values in a clear, intuitive naming.
+ Also renamed the 'checkAndSetStickInputs' function name to 'checkAndUpdateStickInputs', since 'set' doesn't imply that the stick values are update, which is the most important aspect of this function, thus avoiding possible confusions ;)
Matthias : getThrottle() function was ambiguous, wasn’t obvious that it’s 0 centered : [-1, 1]
Is the throttle [0, 1] range or [-1, 1]?
How do we differentiate the spring-loaded self-centering throttle controllers & non-spring loaded controllers?
Parameter Naming Convention
PX4:potaito/new-follow-me-task
← junwoo091400:followme_refactor
There was this discussion 3 years ago exactly about this issue. And it removed a… ll these 'readable' parameter variable names in the code, and reset them to match exactly the parameter name. Could you review this as well for the final decision? thinking @tstastny @potaito
https://github.com/PX4/PX4-Autopilot/pull/11686
Mode Switching / Commander architecture refactor - Thomas
Thinking about how to create a better API for flight modes
Have compiled a document for proposal
Feel free to visit the document above and leave your comments / thoughts!
Enable compile time selection of including specific flight modes for each vehicle / board targets
Ultimate goal is to have an offboard computer send over the flight mode (even python scripts!) to the FMU, and dynamically register as a new flight mode.
Let’s build a nice API on FMU side
Will be uploaded to the Github Issue
Feedback
If you have any feedback or corrections please comment on this post!
Component Updates
Updates on each sectors of PX4 System
VTOL & Fixed Wing
Multicopter
System Architecture
OS / NuttX
Driver
Commander
Simulation
MAVROS / DDS / ROS2
UAVCAN