Discord is the easiest way to communicate over voice, video, and text. Chat, hang out, and stay close with your friends and communities.
Community Announcement
Community Q&A
General Discussions
Check out the release notes here:
PX4 is the Professional Autopilot. Developed by world-class developers from industry and academia, and supported by an active world wide community, it powers all kinds of vehicles from racing and cargo drones through to ground vehicles and...
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 Discord or create a Github Issue !
If you take over 5 minutes for the question, please continue in Discord or a Github Issue.
What happens when we reach the end range (255) of ORB ID?
Currently in this PR: [WIP] ROS 2: Library with dynamic modes API by bkueng · Pull Request #20707 · PX4/PX4-Autopilot · GitHub , we have overflow of ORB ID enums.
Answer: We can switch to uint16_t for uORB ID, but need to check if the performance degrades - Daniel
Note, there’s also some PR that tried to address this: U orb msg limit by hskrieg · Pull Request #20637 · PX4/PX4-Autopilot · GitHub
PX4:main ← PX4:pr-rover-ratesp
opened 01:49PM - 21 Aug 22 UTC
## Describe problem solved by this pull request
Previously USVs(boats) did not … work in mission mode due to the lack of low level control in the rover position control. Due to the low yaw damping on water the boat model would just oscillate on the yaw axis without meaningful navigation.
## Describe your solution
This PR adds a rate control loop on the rover position control module and enables way point navigation for boats.
- Added rate control of a rover using the common rate control library
- Added support for Acro mode for rovers (includes https://github.com/PX4/PX4-Autopilot/pull/18317)
- Had to make commander consider boats as a rover vehicle type for waypoint acceptance (Fixes https://github.com/PX4/PX4-Autopilot/issues/19045)
- This PR needs a modification of the gazebo model for Improved control authority and directional stability of the gazebo boat model https://github.com/PX4/PX4-SITL_gazebo/pull/895
## Test data / coverage
### After PR
Tested in SITL and demonstrated successfully of following a survey pattern
```
make px4_sitl gazebo_boat
```
- Flight log: [Log](https://review.px4.io/plot_app?log=c14bff87-6756-438c-9362-1f42c19e1d2d)
### Before PR
- Flight log: [Log](https://review.px4.io/plot_app?log=5c69e211-0a61-4abd-a6b9-20707fa7b193)
## Additional context
- This is a extended PR of https://github.com/PX4/PX4-Autopilot/pull/18317
- @junwoo091400 This should be useful for https://github.com/PX4/PX4-Autopilot/pull/19957
- Fixes https://github.com/PX4/PX4-Autopilot/issues/19045
- Depends on https://github.com/PX4/PX4-SITL_gazebo/pull/895
Lawnmower application was good, especially yaw rate controller. When would we get this in main branch? It seems very valuable.
The changes make sense, we should have brought it in as experimental feature. Need to check the merge conflicts.
Will bring this up in next week’s maintainers call and likely merge it.
PX4:main ← farhangnaderi:pr-fix-ci-set-output
opened 09:37AM - 13 Jul 23 UTC
### Solved Problem
The 'set-output' function is deprecated and needs to be repl… aced. As @mrpollo mentioned I tried to make the changes.
### Solution
- Replace the deprecated 'set-output' function with the recommended alternative 'echo ::set-output'.
### Changelog Entry
For release notes:
"Replaced deprecated 'set-output' function with 'echo ::set-output' in Ci "
### Alternatives
We could also continue using the deprecated 'set-output' function, but it's recommended to use the new syntax.
### Test coverage
- Unit/integration test: N/A (No changes impacting tests)
- Simulation/hardware testing logs: N/A
### Context
N/A (No specific context or related links for this PR)
Would be better to have minimal changes and only change the set-output part, and keep the whitechange / formatting PR separately.
John is making progress on:
PX4:main ← dirksavage88:remote_id_arm
opened 01:27PM - 28 May 23 UTC
-Changed operator position to Live GNSS: To test you will need a tablet/laptop … with built-in GPS or a USB GPS receiver module. Using QGC daily (they have merged the Remote ID support) you will need to select remote ID in the settings -> https://github.com/mavlink/qgroundcontrol/pull/10600
-Added prototype arm status through the health and arming checks module. This is just for testing purposes and the actual implementation can be different. If you have remote ID enabled but don't have a module plugged in, you will still be able to arm. However if you have a module plugged in and it is not receiving valid GPS or some other failure in operator ID or basic ID it will result in a preflight fail and not allow you to arm.
-Added mavlink receiver support for drone ID arm status
According to David Sastre we are trying to verify the following settings:
**GPS indicator:** If set to FIXED, it will go green if valid lat/long is introduced. If it is set to LIVE, it will go green if valid GPS is received, and latest GCS GPS info is received less than 5 seconds ago. It will go red otherwise. Also, if it is set to LIVE, but region is set to FAA, it will go red if GCS GPS doesn't provide altitude ( needed for FAA region ), but for EU this doesn't apply as altitude is not mandatory.
**Basic ID:** will go green if the armstatus message received is "GOOD_TO_ARM". It will go red if armstatus message reports an error string "missing basic_id message". This is not ideal, but it is the only way given the circumstances of detecting precisely when it is just Basic ID failure. A bitmask or something in armstatus message will be more appropriate, but these are the cards we can play with.
**Arm status:** will go green if armstatus message is good. If armstatus message contains errors it will go red.
**Comms indicator:** will go green as soon as we receive an armstatus message. Will go red as soon as the timeout ( 2.5 seconds ) expires with no message received.
**Operator ID:** will only check if the data set in QGC is valid, not empty and valid ID type.
working with emergency status. This could be its own PR separate from 21647?
Discussion (also on discord ):
Right now, the BASIC_ID can be tampered easily, and is not ‘protected’, this needs to be improved
EMERGENCY button in QGC currently doesn’t affect the status of Open Drone ID to emergency. Sending some kind of MAVLink command would be sensible
Answer:
We should take care of added uORB topics, and MAVLink default streaming changes
Probably we should rely on ‘Mavlink Forwarding’, instead of having to go through uORB.
Stripping it down and making just the essentials stay for the uORB would be better.
Does ‘ARM STATUS’ streaming out depend on the incoming data?
Dronecode is interested in funding the development, so contact Ramon if you are interested!
Will have a dedicated Remote ID discussion next week Thursday - Andrew, Daniel.
Example CubeID to purchase: Cube ID | CubePilot – IR-LOCK
High ram usage on main with an older board:
opened 04:10PM - 11 Jul 23 UTC
uavcan
bug-report
v1.14
### Describe the bug
High ram usage (maxed) on main using the FMUK66 by Nxp.
…
### To Reproduce
This is with uavcan enabled and active connections to a uavcan gps+mag. Could not open a system console or console commands not recognized due to max ram usage. Nothing else out of the ordinary running (see screenshot). There is 256k ram on this FMU
### Expected behavior
Could not replicate on stable/1.13 where ram usage was not causing issues.
### Screenshot / Media
### Flight Log
Will send log on discord at request (dm)
### Software Version
Main
### Flight controller
FMUK66
### Vehicle type
Multicopter
### How are the different components wired up (including port information)
_No response_
### Additional context
_No response_
With the ARK GPS, using UAVCAN
On v1.13, the RAM usage seems normal and UAVCAN seems to work fine
Answer:
Alex: Did unnecessary UAVCAN topics disabled in the build part?
Which MAVLink streams are enabled?
The Board ID in firmware.prototype and defconfig in nsh doesn’t match up, so .px4 binary can’t be uploaded
After flashing the bootloader, Vendor ID and board ID shows up as “Holybro Durandal v1”, but then after flashing the .px4 binary, next time in QGC it shows up as Pixhawk V6U, how can this bootloader change?
Also the sensor rotation was wrong, etc. Will create a specific issue for this for more detail.
Related PR: boards/matek/h743: consolidate and fix h743 variants by dagar · Pull Request #20726 · PX4/PX4-Autopilot · GitHub
It’s especially tricky because we can’t automatically ‘detect’ which variant it is in the board. Also, not having to set new bootloader for PX4 purposes, and allowing to flash straight out of the package would be a great customer experience.
There’s a company wanting to have one of their new H743 ii13 based board supported in PX4
Community Announcement
Community Q&A (No deep technical discussions)
Guideline for asking a Question
General Discussions