rroche
December 28, 2022, 6:01pm
1
Community Announcement
Community Q&A
Project Updates
General Discussions
Weekly Overview
High priority queue
Release
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.
Fixed-wing commands were being used in MC mode, so control surfaces were acting like a plane (when it shouldn’t)
Control surfaces are jittering a lot!
PX4:main ← PX4:pr-3d-tailsitter
opened 07:15PM - 03 Jan 23 UTC
<!--
Thank you for your contribution!
Get early feedback through
- Dronec… ode Discord: https://discord.gg/dronecode
- PX4 Discuss: http://discuss.px4.io/
- opening a draft pr and sharing the link
-->
### Solved Problem
I am trying to build a Tailsitter VTOL where attitude control is only done with control surfaces. However, when a tailsitter VTOL is in multicopter mode, the control surfaces were not being properly actuated when using control allocation, (when the control surfaces were not locked)
- FW attitude control messages were being consumed while the vehicle was in MC mode, and therefore the setpoints were wrongly controlled
### Solution
- Add case to use mc controller outputs for control surfaces when the vehicle is MC mode and the control surfaces are not locked
### Test coverage
- Tested on a 3D airplane platform, where there is one motor and ailerons, rudder, and elevator
- [Video of control surface deflection](https://youtube.com/shorts/axqcYFl4ewQ)
- Flight log of hand-held hover: [flight log](https://review.px4.io/plot_app?log=5963fa16-16a0-4fa3-b019-1ca59882153c)
### Additional context
- @tstastny @sfuhrer Am I right to conclude that the tailsitter was broken for control allocation? the current logic seems to control the attitude based on the fixed-wing attitude controller outputs, and not the `mc_att_control` outputs. Or is this actually correct that we want motors controlled by `mc_att_control` and control surfaces with the `fw_att_control`? (Confused whether the controller separation is based on vtol state (hover, fixed wing) or actuators)
https://github.com/PX4/PX4-Autopilot/blob/315c075e5c7550a88182b42ff2e4f4a86f5f3cb3/src/modules/vtol_att_control/tailsitter.cpp#L364-L369
Simulation: Flip stream? not modeled
Want to define the ‘port’ to use for telemetry for.
Following Mavlink example: PX4-Autopilot/src/modules/mavlink/module.yaml at main · PX4/PX4-Autopilot · GitHub
Answer: Telem2 and all are generated for each board in a different file (?) by a python script, and that should be used, instead of defining in the parameters itself.
PX4:main ← PX4:pr-fw-rate-control-module
opened 01:39PM - 18 Sep 22 UTC
## Describe problem solved by this pull request
The `fw_att_control` module wer… e controlling both attitude and body rate setpoints. While this has been working great, this makes it hard to integrate other control methods on either side of the cascasded loop.
Therefore, this PR proposes adding a separate `fw_rate_control` module that pulls out the rate control functionality from the `fw_att_control` module.
## Describe your solution
This PR adds a fixed wing rate control module, where we can potentially swap out the controller to other controllers(out of tree modules)
Adding the rate controller as a separate module has the following advantages
- We can run the rate controller at a faster rate, that is appropriate for attitude control
- makes the control framework more modular, for example we can now switch the rate controller to different rate control methods (e.g. indi @kimnerd FYI)
- Cleaner interface between rate control and attitude control so that the interface for each cascaded control is clearly defined
- This moves us closer to a unified rate controller for VTOLs
This is still a WIP, and I have noticed a few things that needs to be resolved before we can actually merge this approach
- [x] This PR breaks the wheel controller - We need to decide on how to handle wheel controller (https://github.com/PX4/PX4-Autopilot/pull/20537)
- A lot of information is just getting passed to the attitude controller just for the wheel controller
- [x] Decide on how to handle flap controls (Currently being passed through attitude setpoints)
- Why are flaps part of the attitude setpoint?
- [x] The `fw_rate_control` still needs to subscribe to `vehicle_attitude_setpoint` message since the reset rate integral is included in the `vehicle_attitude_setpoint` (https://github.com/PX4/PX4-Autopilot/pull/20502)
## Test data / coverage
Tested in SITL
## Additional context
- This is a continuation of https://github.com/PX4/PX4-Autopilot/pull/20080
Wheel control: will be dealt with along with ECL
There’s 2 X500 V2 documentation. This is confusing.
We can merge these docs?
Holybro sells X500 V2 with Pixhawk 6C.
Discord thread: Discord
For Pixhawk 6C, the IO vs FMU pinout can be confusing.
IO and FMU are labeled ‘MAIN’ and ‘AUX’ in the products, this is confusing.
Related to the thread above (regarding X500 V2).
PX4:main ← PX4:pr-mavlink_iridium_minor
opened 09:47PM - 21 Dec 22 UTC
- disable events, forwarding, ftp
- HIGH_LATENCY2 send raw GPS lat/lon/alt if … global position estimate isn't available
Recently updated Issues / PRs in PX4-Autopilot Link
Pull Requests Issues
PX4 Dev Call: April 27, 2022
Discussion based on: High-Priority Queue · GitHub
man_up
January 4, 2023, 1:45am
2
At what time is the call tomorrow?
I need to discuss about proposed changes by @DonLakeFlyer for X500 V2 in addition to docs pages to be organized for it!
1 Like
Community Announcement
Community Q&A (No deep technical discussions)
Guideline for asking a Question
Project Updates
General Discussions
Weekly Overview
Github
Slack
Last Dev-Call
Release