The yaw pointing towards the center makes sense since that's the approach
direction anyways. But with the yaw feed forward results in a weird looking
bias when not orbiting yet.
The condition that the vehicle is more than 3m away from the circle line
was too sloppy. That often happens when the radius is changed by sticks.
A reapproach is only necessary when the center is moved and that's only
possible through the orbit command.
The initial approach to the circle to orbit on was very agressive since
it was just the controller trying to stay on the circle reaching the
limits. Now there's first an approach phase in which the vehicle reaches
the circle trajeectory in a smooth perpendicular line before starting the
orbit execution.
Before it was:
- not used anywhere
- copied from an old mission implementation version
- didn't plan in advance
- had a lot of broken cases
- dependent on a lot of parameters
I'm starting with a new relatively simple implementation that works as
expected for a minimum viable implementation and can be improved over time.
The first version is used to approach the circle path in Orbit mode to
verify the interface and get testing such that it gets eventually used
everywhere.
Script to update include paths:
for i in $(grep -rl 'include <px4_work_queue' src platforms); do sed -i 's/#include <px4_work_queue/#include <px4_platform_common\/px4_work_queue/' $i; done
This changes two things:
- This adds "-beta" as a valid tag suffix.
- This changes "rc" without "-" to "-rc". "rc" without is now described
as deprecated and with "-rc" is preferred.
It was broken because _velocity_setpoint is used for input and output
and was assumed to be the input at a place where it was already overwitten
To clarify this, the input setpoint is renamed "target"
* Add kdevelop to gitignore
* Add test stubs
* Rename px4_add_gtest to px4_add_unit_gtest
* Add infrastructure to run functional tests
* Add example tests with parameters and uorb messages
* Fix memory issues in destructors in uORB manager and CDev
* Add a more real-world test of the collision prevention
Also remove crosstrack P controller that produces overshoots when the
acceptance radius is large (crosstrack error is suddenly large at
waypoint switch).
This new airspeed module does:
-runns an airspeed validator for every airspeed sensor present, which checks measurement validity and estimates an airspeed scale
-selects another airspeed sensor if for the current one a failure is detected
-estimates airspeed with groundspeed-windspeed if no valid airspeed sensor is present
-outputs airspeed_validated topic
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This validator takes measurements from a single airspeed sensor and:
-checks validity of measurement
-can estimate an airspeed scale factor (estimation enabled with parameter setting) to accout for errors in airspeed due due placement of sensor
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Beat Küng