rroche
July 6, 2022, 5: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.
@mwbb has issues with CubeOrange as of this issues. Added screenshot from Radio connection. However as in serial connection logger and Mavlink shell seems not to be working.
opened 04:17PM - 23 Jun 22 UTC
bug-report
## Describe the bug
I am not able to access the mavlink console in QGroundContr… ol or through the python script in 1.13.0.
## To Reproduce
Steps to reproduce the behavior:
1. Flashed newest firmware (1.13.0)
2. Open QGC
3. Click analyze tools
4. Click console and hit enter
5. No response
## Expected behavior
Expect nsh> to appear. No response
## Drone (please complete the following information):
- Cube Blue, Standard carrier board
Thank you
Dane Johnson
I would like to open discussion on these PR / Issues, as they can be useful if we review / merge them, but hasn’t been touched in ~2 years! - @junwoo0914
PX4:main ← PX4:pr-smart-rtl
opened 08:05AM - 06 Jun 17 UTC
This adds graph-based "smart" RTL capabilities from @samuelsadok :
Adds Smart … Return To Home capability by recording the flight path in a memory optimimized format. This means the UAV can return to home by using only known-good flight paths.
The flight graph is stored as a series of delta elements at 1m resolution and a list of nodes. Both lists share the same buffer. Each delta element takes up 2 bytes or sometimes 6 bytes if the delta is large. The path can consist of multiple disconnected segments, in which case the gaps are stored as delta elements with a jump-bit set.
Once in a while or when required the graph is consolidated, which means:
- Points that lie roughly in a line are replaced by a single line
- Points that lie close to previously recorded lines are pruned
- For lines that pass close to each other a node element is created
Furthermore:
- The graph is recorded at a higher precision closer to home
- If the graph becomes full, the overall precision is reduced and the whole graph is re-consolidated
- If the graph becomes full once more, all data is removed except for the shortest path home at that moment. One of these actions is repeated at each subsequent fill-up.
Path finding information is generated/refreshed on demand and stored in the nodes. During return-to-home, the best direction to home is continuously evaluated by using the information stored in the nodes.
The graph recording and path finding is implemented in navigator/tracker.cpp.
The graph based return-to-home is implemented in navigator/smart_rtl.cpp. by Samuel Sadok
opened 01:44PM - 17 May 16 UTC
enhancement
pinned
It would be nice if the land detector would robustly detect when the vehicle has… landed upside down or just flipped when landing.
opened 04:38PM - 15 Apr 17 UTC
enhancement
pinned
Commander has become unmanageable. After the next stable release goes out let's … decide on a path forward for a rewrite or major restructuring.
@LorenzMeier @bkueng
I believe https://github.com/PX4/Firmware/pull/6750 is the only major commander work in progress.
Relevant - https://github.com/PX4/Firmware/pull/6955
**Notes and Ideas**
* do a pass and remove everything that doesn't belong in commander
* define what commander should and shouldn't be responsible for
* ~~create new commander c++ class using blocklib for params and subscriptions, publications~~
* subsystem_info still used?
* Find a better home for ROI - see VEHICLE_CMD_DO_SET_ROI
* Calibration switch to matrix and move out of commander - https://github.com/PX4/Firmware/pull/6513
* FW engine failure new home - https://github.com/PX4/Firmware/issues/6958
* Consider generating or verifying the various state machines? https://github.com/PX4/Firmware/issues/2463
* move all handling of manual_control to the stick_mapper. Stick mapper can publish vehicle commands to change modes or arm/disarm.
* write a simple vehicle_command command line app to publish vehicle commands. This replaces commander arm, takeoff, etc
* px4_custom_mode.h and mavlink VEHICLE_MODE_FLAG - only use in mavlink module, which can then publish a vehicle command
* how to handle low priority loop?
* ~~sanitize test commands (gps_failure_cmd, rc_signal_lost_cmd, etc). These should be forcing the regular flag, and not independent~~
* how can we write meaningful testing?
* kill vtol_fw_permanent_stab
* kill old style switches? https://github.com/PX4/Firmware/issues/6611
* should vehicle_control_mode_s flags be an array?
* commander should be the definitive source of supported commands
* bring all preflight checking together encapsulated in a new class. The commander main loop shouldn't be looking at individual sensors, etc
* use event interface - http://discuss.px4.io/t/event-interface/2318
* does commander need to publish the first mission_state?
* handle led and buzzer in events?
* ~~review hotplug~~
* significantly better error reporting for denied transitions. This is a huge source of confusion for new users. Messages need to be actionable.
* properly track previous main_state. https://github.com/PX4/Firmware/issues/7947
Issue Tracker
* [ ] move calibration out of commander
* [ ] move all stick mode mapping to stick_mapper (use vehicle_commands to change mode or arm)
* [ ] geofence handle in navigator (publish mode changes for violation)
* [x] create new commander c++ class using blocklib for params and subscriptions, publications @dagar #7517
* [ ] expand preflight_sensor and remove direct sensor subscription from commander
* [x] Find a better home for ROI - see VEHICLE_CMD_DO_SET_ROI
* [ ] preflight refactor, this alone is a massive task
* [ ] review all status_flags_s (some are filled improperly, some aren't used, some should be used)
* [ ] move FW engine failure detection to the FW attitude controller
* [ ] move px4_custom_mode.h and mavlink VEHICLE_MODE_FLAG to mavlink module
* [ ] explore state machine generation options @dagar (https://github.com/PX4/Firmware/issues/10584)
* [ ] centralize and simplify system_power and battery status for preflight checks, arming, failsafes, etc. Commander should only have a few overall status flags to check @dagar @davids5
* [ ] land detector can print it's own status
opened 03:30PM - 17 Feb 18 UTC
bug
fixedwing
more_info_needed
stale
When trying to use a gimbal (vmount) on FW or VTOL there are multiple actuator_c… ontrols_2 publishers.
https://github.com/PX4/Firmware/blob/8b3716c0df292ddda71a6114d55ad9df2e7ff37d/src/modules/fw_att_control/FixedwingAttitudeControl.cpp#L854
Recently updated Issues / PRs in PX4-Autopilot Link
Pull Requests Issues
PX4 Dev Call: April 27, 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
(for discussion)
Weekly Overview
Github
Slack
Last Dev-Call
Release