This adds a sitl target and aiframe configs for the r1_rover, which is a differential rover example for SITL rover. The model is based on the aion robotics r1 rover
- Avoid constantly adjusting the velocity gains with the HTE
- Make sure the hover thrust integral update doesn't break
even though its unit is acceleration and not unit thrust anymore
We need to convert the velocity gains to not contain/depend on the
hover thrust. In horizontal direction it doesn't make sense to scale
them with the hover thrust and in vertical direction the adjustments are
already done in the acceleration to collective thrust conversion.
- create common uORB::PublicationBase
- uORB::PublicationQueued types are now type aliases
- ORB_PRIO use enum type everywhere to avoid accidental misuse
- PX4Accelerometer/PX4Gyroscope/etc driver libs explicitly advertise on construction, unadvertise on destruction. This is a workaround for any potential issues that might appear when accel/gyro cdev and uORB indexing doesn't align.
Because the takeoff ramp is a vertical velocity limit ramp for the
nice user experience but the acceleration feed-forward can
add on top of the output and depending on trajectory generation
result in unwanted thrust changes during the ramp.
* Land Enabled
* Declared Subscriptor in header as originally intended.
In the header it caused SIGSEGV in my machine so that's why it was moved
to .cpp
* Code Style fixed
* Removed confusing comments
* Comment update
Co-authored-by: Julian Oes <julian@oes.ch>
* VTOL type: add new parameter VT_FWD_TRHUST_EN for customizing pusher/tilt assist
Depending on the setting of this param, the pusher assist is:
-completely disabled (default)
-enabled in pos, alt and auto mode (except LAND)
-enabled in pos, alt and auto mode if above MPC_LAND_ALT1
-enabled in pos, alt and auto mode if above MPC_LAND_ALT2
-enabled in pos, alt and auto mode
(before it was always disabled in LAND mode)
-change default of VT_FWD_THRUST_SC from 0 to 0.7
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Instead of blocking the receiver thread while playing a tune we now copy
the tune to a buffer and check if we can play the next note on each
iteration of the receiver thread.
The buffer and tune object is only created on the heap if we receive a
tune to play once and doesn't use resources otherwise.
The old tune device interface is not working anymore and we need to
publish to uORB tune_control.
This solution is not optimal though because blocks the receiving thread.
Daniel Agar