_ #14099
Closed
_ #14099
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some of these perf counters were useful during initial development, but realistically aren't needed anymore, some are redundant when we can now see the average interval from `work_queue status` and some of them simply aren't worth the cost at higher rates.
* ekf2: Add FirstOrderLpf and InnovationLpf classes for innovation lowpass filtering * ekf2: use InnovLpf filter class in preflight checks * ekf2: move selection of yaw test limit for pre-flight check in function * ekf2: Move pre-flight checks into separate function * ekf2: use static constexpr insetead of inline for sq (square) function * ekf2: Split pre-flight checks in separate functions Also use the same check for all the innovations: innov_lpf < test and innov < 2xtest * ekf2: Add optical flow pre-flight check * ekf2: Combine FirstOrderLpf and InnovationLpf in single class * ekf2: check vel_pos_innov when ev_pos is active as well * ekf2: transform InnovationLpf into a header only library and pass the spike limit during the update call to avoid storing it here * ekf2: Static and const cleanup - set spike_lim constants as static constexpr, set innovation - set checker helper functions as static - rename the mix of heading and yaw as heading to avoid confusion * ekf2: use ternary operator in selectHeadingTestLimit instead of if-else * ekf2: store intermediate redults in const bool flags. Those will be used for logging * ekf2: set variable const whenever possible * ekf2: create PreFlightChecker class that handle all the innovation pre-flight checks. Add simple unit testing Use bitmask instead of general flag to have more granularity * PreFlightChecker: use setter for the innovations to check instead of sending booleans in the update function This makes it more scalable as more checks will be added * ekf: Use booleans instead of bitmask for ekf preflt checks Rename "down" to "vert"
Signed-off-by: RomanBapst <[email protected]>
The AUR repository got fixed upstream after I reported the issue. I tested on a fresh machine so we can get rid of the workaround that was necessary. See https://aur.archlinux.org/packages/ignition-cmake/#comment-712301
dt could drive the alpha filter crazy because of the small dt approximation during the computation of the coefficient. - Remove unused bitmask packing of the innovation checks
…optical_flow topic). (#13257)
- sitl_gazebo in PX4/Firmware (ffefd45): PX4/PX4-SITL_gazebo-classic@c0634b2 - sitl_gazebo current upstream: PX4/PX4-SITL_gazebo-classic@169d482 - Changes: PX4/PX4-SITL_gazebo-classic@c0634b2...169d482 169d482 2019-10-22 Julian Oes - travis: let's not bother about macOS Sierra 78fef51 2019-10-22 Julian Oes - travis: install gstreamer using brew 764d1b7 2019-10-21 Julian Oes - models: fix reported validation errors 053622b 2019-10-11 TSC21 - Travis CI: Cleanup scripts and add more MacOSX build pipelines 0c8214c 2019-10-21 Julian Oes - cmake: fix Qt prefix path for macOS bb2c08c 2019-10-06 TSC21 - CMake: fix Qt5 find in MacOS 81f072b 2019-10-14 Julian Oes - travis: install GStreamer using brew 39d4399 2019-10-14 Julian Oes - cmake: link to glib-2.0 and gobject-2.0 fef3ff5 2019-10-14 Julian Oes - cmake: fix GStreamer and Qt deps for macOS 605da22 2019-10-22 Nuno Marques - Update README.md 2a8a54e 2019-10-20 Nuno Marques - README: update install instructions
The constrainAbs function was not prioritizing the minimum value that produces the autocontinue behaviour. This caused zig-zag paths when the waypoints were almost -but not exactly- aligned.
I don't understand why we should wait to parse incoming MAVLink traffic just because we don't have the source address initialized. We still check the source address before doing a sendto. This should fix serial MAVLink communication on FMU5x where both serial and UDP is available. There the serial connection previously did not work because nothing was connected over UDP.
We should still accept messages arriving over serial.
- this is currently necessary for the QGC power setup gui, but should be reverted in the future - fixes #13292
* NuttX/nuttx with SDIO fixes
getLockGuard relies on copy elision to work correctly, which the compiler is not required to do (only with C++17). If no copy elision happens, the mutex ends up being unlocked twice, and the CS is executed with the mutex unlocked. The patch also ensures that the same pattern cannot be used again.
This fixes the case where the mixer_module would subscribe and use its own test_motor publication which was created only to make sure the topic is advertised and subsequent updates will work properly. This happened in SITL lockstep because the timestamp would be 0 at the very beginning, and hence elapsed time would be 0 as well. This lead to an actuator publication which would then get lockstep out of sync causing poll errors on the Gazebo side.
Signed-off-by: Silvan Fuhrer <[email protected]>
read_word() expected 3 bytes (uint16_t + PEC byte), but was passed an address to an uint16_t value. write_word() is changed to be type-safe as well.
Note: the author name was removed because this file has almost no resemblence with the code written by that author 4 years ago, has been copied to new places, and was initially commited without author anyway. Also, my opinion is that the version control system should take care of attribution, and not outdated comments.
This fixes spuriously occuring mag spikes in the external mag of Here2. The reason for the spikes was that the fact that the I2C registers were not read out correctly as suggested in the datasheet. Before we were reading out ST1, data, and ST2 in one pass and ignoring the data ready bit (DRDY) in ST1. This meant that we could run into race conditions where the data was not ready when we started reading and being updated as the registers are read. Instead, we need to check the read the ST1 register first to check the data ready bit and then read the data and ST2 if the data is ready. By reading ST2 we then trigger the next measurement in the chip.
The interrupt driven card detect logic was enabled but the auto mounter was not. That interrupt was calling mmcsd_mediachange. There is a reentrancy issues in the kinetis callback logic. Toplevel calls mmcsd_mediachange calls SDIO_CALLBACKENABLE that calls kinetis_callbackenable that calls kinetis_callback that calls mmcsd_mediachange.
When running in HITL mode, pwm_out_sim publishes actuator_outputs. px4io unconditionally publishes the uOrb actuator_outputs. When HITL is configured, the px4io copy of the uOrb has all zeros. The result is that there are two publications, one valid, and one all-zeros. This causes the HIL_ACTUATOR_CONTROLS mavlink message to be incorrect (all-zeros) and the SERVO_OUTPUTS_RAW mavlink message to be inconsistent, as it takes the data from one or the other uOrb randomly each cycle. The fix is to let px4io know that HITL is in effect when it is started, and modify px4io to suppress publication in this case. This is a bigger more complicated fix than I would like, but I think it is conceptually correct. Signed-off-by: Nik Langrind <[email protected]>
This confused me, so hopefully it will help the next user, e.g. me.
_generation is read in a multi-threaded context w/o locking.
No semantic change (yet)
Possible race conditions (they all happen between the check of existence of a topic and trying to create the node): - single instance, with multiple advertisers during the first advertise: both advertisers see the topic as non-existent and try to advertise it. One of them will fail, leading to an error message. This is the cause for telemetry_status advert failure seen in SITL in rare cases. - multi-instance: subscription to non-existing instance -> px4_open fails, and the subscriber tries to create the node. If during that time a publisher publishes that instance, the subscriber will get (instance+1) (or fails if the max number of instances is exceeded). This is a race that goes pretty much unnoticed. - multi-instance: 2 publishers can get the same instance (if is_published() is false in case both have not published data yet). This can also go unnoticed. Therefore the patch changes where _advertised is set: it is now set directly during the advertisement instead of during publication.
Exclusive open is not required, but we now need to ensure the queue size is set atomically. It avoids a race condition between 2 single-instance advertisers, where one of them would fail to open the node with -EBUSY.
The navigator has a notion of resetting the triplets which means the triplet setpoints are set to invalid and therefore not to be used by downstream modules such as flight tasks. However, before this patch, the triplets were not published if invalid meaning that a valid triplet would stay the truth until a new valid triplet would get published. E.g. this lead to the corner case case where we publish a valid triplet with an IDLE setpoint on ground in HOLD and then don't update the triplet while flying in POSCTL mode. Later, when RTL is engaged, the flight task will use IDLE until navigator (which runs slower) has published the next triplet. The fix involves two main changes: - Publish invalid triplets to avoid stale triplets. - Avoid publishing the triplet on every iteration in manual modes by not setting `_pos_sp_triplet_published_invalid_once = false`. When testing this I realized that a mission upload during RTL would stop RTL. This is because the mission is updated while the mission navigation mode is not active and reset_triplets() is called from there. This is now only done for the case where we are actually in mission navigation mode. The fact that a mission is updated when not active also seems wrong and is something to fix another time.
Open the UART after adding the instance: mavlink_open_uart() might block, and in that case the parent task waiting for mavlink to be started times out. And while waiting for the USB UART device to come up: - check for _task_should_exit - check for check_requested_subscriptions() Side-effects when USB is not plugged in during boot: - reduces boot duration by 100ms - fixes duplicate instance name in 'top': 201 mavlink_if0 1 0.000 1328/ 2572 100 (100) w:sig 3 204 mavlink_if0 572 4.221 1632/ 2540 100 (100) w:sig 4 - 'mavlink stop-all' now stops the usb instance as well
This fixes a corner case for VTOL RTL with RTL_TYPE 1. RTL_TYPE 1 means that the VTOL skips all waypoints on RTL and jumps to the land waypoint at the end. During a mission in fixedwing mode it will continue to fly in fixedwing mode and then do a transition before landing. However, if RTL is engaged right at the moment of the front transition, the transition waypoint is not inserted and the VTOL will try to land in fixedwing mode at the mission land location. This corner case is fixed in this patch by also considering the "transition after takeoff" state.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please use PX4 Discuss or Slack to align on pull requests if necessary. You can then open draft pull requests to get early feedback.
Describe problem solved by this pull request
A clear and concise description of the problem this proposed change will solve.
E.g. For this use case I ran into...
Describe your solution
A clear and concise description of what you have implemented.
Describe possible alternatives
A clear and concise description of alternative solutions or features you've considered.
Test data / coverage
How was it tested? What cases were covered? Logs uploaded to https://review.px4.io/ and screenshots of the important plot parts.
Additional context
Add any other related context or media.