new versions of logger does not allow to log multiple instances of a topic when using 'logger_topics.txt'
This commit restores the default behavior (log all instances of a topic) and ad the option to specify an instance to log
This allows us to print an error message instead of a weird Java failure
further down the road.
Better yet would be if this would take down everything, so a user does
not have to scroll up to read the message.
These assignments were temporary for correct logging of the input
setpoint which now properly also comes out of the controller again.
This is reverting the hotfix from:
dee8d200d8bb42cd964065f9a6506e3c4a901f10
Removing the skip_controller and interfaceMapping
concept and replacing it with a single method checking
if the position control update was successful and
return the result in the PositionControl.update().
This restores original horizontal thrust setpoint execution
that I intentionally broke three commits ago. It's necessary
for correct stick to tilt mapping of FlightTaskManualAltitude.
This commit temporarily breaks direct horizontal thrust setpoint execution
which is used by FlightTaskManualAltitude. This is necessary to allow for
PositionControl cleanup namely calculating the whole velocity PID in one
Vector3f formula.
Having this in a separate commit is useful since it reduces indentation
of a bigger code block.
* workflows: remove unneeded pip dep and comments
* mavsdk_tests: simple test using flow/offboard
This adds a first proof of concept of a test using flow and offboard.
* Flow MAVSDK test: check against ground truth
* CleanUp
* workflows: use latest docker image with psutil
* mavsdk_tests: fix PEP8 issues
* Add VTOL CI tests back
* switch to non-rendering flow mockup
* workflows: install mavsdk from GitHub release .deb
* Add vision test and disable VTOL temporarlly
* Fist draft of combining test coverage and test in one workflow
* Add VTOL mavsdk tests back in CI
Co-authored-by: Julian Oes <julian@oes.ch>
Co-authored-by: kritz <kritz@ethz.ch>
I've added a queue depth of 4 for sensor_accel and sensor_gyro. This is initially added because it's not always possible for the `vehicle_acceleration` to keep up with every publication of the primary accelerator as it runs in the same thread as ekf2, various controllers, etc.
Later this mechanism will be used in a few areas
- rate limit `vehicle_angular_velocity` and `vehicle_acceleration` without missing any raw data
- move IMU integration to `vehicle_imu` and out of the actual driver threads, eliminating the need for sensor_accel_integrated and sensor_gyro_integrated
- integrate raw gyro synchronized with optical flow measurements
