rroche
September 15, 2021, 5:02pm
1
Community Q&A
Roadmap
High priority queue
Release
In-Depth discussions
Move px4io to FMU
needs help with flight testing
PX4:master ← PX4:pr-px4io_mixer_module
opened 12:24AM - 24 Dec 20 UTC
This moves the mixing out of the px4_io-v2 (stm32f103) and into the px4io driver… FMU side. By handling all the mixing directly in PX4 we'll be in a better position to iterate on system configurability, control allocation, and really anything related to mixing. This also saves a relatively large amount of flash (~ 23 kilobytes).
The downside is we lose full manual control RC passthrough, but that's useless for multicopters, and even for VTOLs where the convention has been to have MC on MAIN and FW on AUX. The px4io can still handle fixed failsafe output values and a manual kill switch, but otherwise all actual work is done on the FMU.
Not yet fully functional, but getting closer.
### TODO:
- [x] ~~kill switch~~
- [x] failsafe positions
- [x] move px4io entirely to WQ
- [x] review in air restart
- [ ] test test test
- [x] watchdog? (we'll bring this in separately https://github.com/PX4/PX4-Autopilot/pull/18086)
Restore old mission if a new mission is not feasible
check if mavlink mission sync can reject a mission, this would help QGC with the user experience
mavlink and navigator should be doing mission checks
TODO: check with maintainers and community and the best approach
PX4:master ← PX4:pr-restore_old_mission_if_a_new_missionis_not_feasible
opened 10:44AM - 17 Sep 21 UTC
**Describe problem solved by this pull request**
This solves the issue describe… d here https://github.com/PX4/PX4-Autopilot/issues/12473
**Describe your solution**
Dataman has space to store 2 missions. This solution will keep one valid mission in Dataman while other space will be used to store new missions. If the new mission is not feasible, it will return to a previously feasible mission.
This solution also includes fixes that were raised when after this feature was implemented.
**Test data / coverage**
It is tested in simulation and real vehicles for the last 6 months.
GPS clock set time updates
needs time from reviewer to test
PX4:master ← PX4:pr-sensors_gps_time_sync
opened 04:02PM - 17 Sep 21 UTC
WORK IN PROGRESS - opening early for discussion and testing
- remove drivers… /gps set clock callback
- drivers/gps try to set sensor_gps timestamp_sample as closely as possible
- move mavlink timesync to new lib/timesync library
- sensors/vehicle_gps_position consume all sensor_gps sources and determine time GPS utc time offset using lib/timesync
- once time offset is stable update system clock if sufficiently different
- updated hrt ts_to_abstime and abstime_to_ts to work relative to CLOCK_REALTIME
- increase drivers/gps priority to reduce timing jitter
Requires https://github.com/PX4/PX4-GPSDrivers/pull/90
TODO
- [ ] review mavlink timesync and test (thresholds may need to be configurable for different usage)
- [ ] improve hrt and time update helpers (critical sections, minimize error)
- [ ] review EKF2 GPS delay? ublox timestamp_sample has shifted by more than 10 milliseconds (closer to truth)
Fix DSM2/DSMX guessing routine and DSM range checking
the protocol is very flexible and it makes it hard to differentiate between DSM v1 vs v2
We discussed solving this problem with two approaches, increasing the time to detect protocol, and allowing the user to set the protocol version via param
PX4:master ← chris1seto:master
opened 02:06AM - 21 Sep 21 UTC
I noticed several issues with the DSM parser.
* Inappropriate range checks in … both channel indexes and channel values
* DSMX/2 guessing routine does not correctly identify otherwise valid DSM2/X from an RX which has a channel payload which does not align with the predefined channel layouts
* A bug in the generation of the `cs10` and `cs11` channel layout word
* Improperly set maximum DSMX/2 channels definition
* Improper handling of channel counts and channel values for channel counts larger than 7
This PR references the following document from Spektrum: https://www.spektrumrc.com/ProdInfo/Files/Remote%20Receiver%20Interfacing%20Rev%20A.pdf
This PR fixes those issues and should probably also serve as a starting point for a more comprehensive discussion about how to correctly detect DSMX/2. The DSM protocol is extremely flexible and also poorly adhered to (even by Spektrum themselves!), and as a result, it's difficult to detect with 100% confidence if a frame (or small collection of frames) is for certain DSMX or DSM2. This PR implements several new heuristics to uphold the previous behavior of automatically guessing whether a stream is either DSMX or DSM2. It is my opinion, however, that given the extreme protocol flexibility allowed within the protocol, and the wide range of implementations in both Spektrum and non-Spektrum RXes, that there should be a param which allows the user to statically set whether to use DSMX or DSM2 parsing.
Notes on range checking:
* For DSMX, at a minimum, channel index bitfield values up to, and including decimal 12 as well as decimal 15 are valid. It's not entirely clear to me from the Spektrum satellite spec document how channel indexes up to 20 are obtained, and there appears to be an implementation of this in the original driver. I don't know if that is correct. A channel index value of 15 means that the channel word is a placeholder and should not be parsed. In this case, the entire word is 0xffff, but channel values covering the entire range should be valid, so I am assuming that it's simply a don't care if the channel index is 15 and that a channel value of all bits set DOES NOT specifically mean that the channel value is invalid.
* DSM can still have a max channel count range check, since it has a larger bitfield for channel index
* I do not believe that range checking is safe on channel values. It's not impossible of for the entire stick range to be legitimately used, and enforcing arbitrary range checks of "reasonable values" could be a time bomb in flight if a slider/stick is moved to a range that wasn't seen in ground testing or in radio calibration. Spektrum implies in their specification document that the entire range of the channel value bitfield is valid.
For the above reasons, there is very limited data to determine that a DSM channel is for sure DSMX or DSM2. The majority of the previous guessing routine utilized range checks such as those.
In this new PR, I introduce several new guessing heuristics. For each DSM2 or DSMX,
1. In all frames seen over the sample period, there must be no channel index gaps
2. Channels must start at 0 and a minimum channel count of 5 is required
3. For each channel seen, it must be seen nearly as often as every other channel seen in the sample period
4. A, individual frame is only valid if it does not contain duplicate channel indexes. Each good frame is counted during the sample period. After 15 frame samples are counted, there must be at least 10 good frames of either DSMX or DSM2
For background, the "system byte" is available to differentiate between DSMX and DSM2 streams, however, it has been the case that the system byte has apparently been reported as incorrectly set in some genuine Spektrum RXes. This means that we cannot use it alone to determine a DSMX or DSM2 stream. One alternative option is to use this byte as it was intended and not guess at all, but also present a param to override the use of the system byte and specifically parse as DSMX or DSM2.
This PR should considerably improve DSM2/DSMX guessing performance, however as a result of the limited information available for determining a valid DSM2/DSMX stream, I would highly recommend the alternative solution mentioned above involving the system byte and the param to override it.
Thanks for @dagar for his help in answering questions about the existing DSM parser and his feedback on a new solution!
HTE: decrease sensitivity with speed
PX4:master ← PX4:pr-hte-sensitivity
opened 07:38AM - 20 Sep 21 UTC
**Describe problem solved by this pull request**
VTOL planes are getting lift f… rom the wing when flying in MC mode at high speed. They (and some other drones) also get extra drag when climbing and descending at high speed, corrupting the hover thrust estimate (HTE).
**Describe your solution**
To avoid this, two speed thresholds (vertical and horizontal) are defined above which the sensitivity of the estimator is decreased by linearly increasing the observation noise.
**Test data / coverage**
Replayed on a log having this issue using https://github.com/Auterion/Flight_Control_Prototyping_Scripts/pull/10
Before this PR, the update was skipped if |vz| > 2m/s:
With this PR, the measurement noise is increased (`_PARAM_HTE_VXY_THR` set to 2m/s) so the estimate isn't biased:
Raise your questions!
If you have any feedback or corrections please comment on this post.
