Before if you were above the maximum altitude you could not command to
go down anymore until the position controller had overshoot to under the
maximum altitude again.
Some threads do not exit and are still running when
trying to exit SITL running under Windows in Cygwin.
This problem was introduced with:
- posix shell #10173 because of strating a child process
for the startup script and mixing up the signal handling
(only Ctrl+C broken)
- lockstep #10648 because of simulator threads not
stopping gracefully anymore with timing race conditions
(no graceful exit possible anymore)
I leave the SIGINT handler on its default implementation for
Cygwin which kills the process and all its threads when pressing
Ctrl+C.
This hotfix at least allows the usage of Ctrl+C again instead
of forcing the user to use the task manager to shut down
px4.exe going crazy on CPU load instead of exiting
everytime.
instead of the derivative of the vertical position which is
not the same value when using the ekf2 estimation.
Using the position derivative resulted in delayed landing because
the value for some reason often bumped over the theshold before
slowly converging towards zero while the velocity was within expected
accuary in all these cases.
There were accidents because when missions lead through an obstacle
and it should be avoided but the setpoints from the external obstacle
avoidance module are suddenly missing the mission is continued into the
obstacle which results in a crash.
In 5bb9babc20 I made MAVLink send a
rounded up integer instead of rounded down. This makes sense in practice
because the low battery reactions happen exactly when the reported number
switches in the UI. But here we want to provoke an exact 50% in the UI so
we stop counting at 49.9%, it get's rounded up and we see the expected
result.
In 3e6e1f5c2b the simulated battery
percentage was reversed. I'm assuming because of the possibly
missleading variable name. Now I'm fixing it by switching the
maximum and minimum voltage such that the name is not misleading anymore
but it still works as expected.
Setting PWM_DISARMED to 0 results in no PWM output to the ESC for the pusher motor.
Most ESCs start beeping endless in short intervals if they don't get a signal.
I remove changing this parameter which is 900 by default to always command the motor to stand still.
Necessary because NuttX defines pollfd differend from
the POSIX standard. The difference of field order makes
use of C++ designated initializers to compile for both
platforms impossible.
If the landed state was set before the position controller starts it
would get updated with the first poll_subscriptions() anyways. But it's
not on all posix and nuttx platforms I tested and the deleted statement
just copies the zero message into the struct which is already zero.
Because it was always failing from the beginning on and
we want to make sure no other tests break in the meantime
by running the currently passing tests also on Windows CI.
to save the time running the installer for every build
which was necessary before because the folder exceedes
the maximum of 1GB cache of the appveyor free plan
to fix Cygwin upload. It failed silently but when catching it prints
"non-standard baudrates are not supported on this platform".
Discussion about platform independet FTDI detection is in issue #10429.
Latest QGC daily supports sending an orbit command. This commit applies
the correct radius, rotation direction, velocity and center position.
Still missing is a check to have global position available and applying
x,y coordinates and altitude independently.
For the geo.h C library to convert between global and local frame
we need an up to date global reference which is currently inside the
vehicle_local_position message.
Switch to positive tangential velocity being clockwise because with NED
frame z-axis points down and mathematically positive around the z-axis
results in clockwise yaw rotation when seen from above. Also MAVLink
messages and other components in PX4 are defined this way.
The handling for vehicle commands inside the FlightTasks library
was already there but commented out because the previously used
MAVLink messages were tied to the specific application we used and
there was no clean common message definition. Because there is now
a well defined message for the orbit task I'm uncommenting and using
the working message handling again here.
Nice smooth altitude control is already provided by the existing
flight task for altitude mode. We inherit from it to resuse the
functionality and just all its update first not altering the setpoints
for the z-axis it produced.
Maximum velocity achievable in 4 seconds,
maximum radius achievable in 8 seconds for futher testing.
These should be parameters as soon as it works fine.
Matthias Grob