- standard vtol was implementing many custom parameters although they
are generic and should be shared between the vtol types
- removed heavy usage of hrt_elapsed_time() which is a system call and
could be computationally expensive
This fixes a problem where we do not properly go to the set takeoff
altitude but end up lower.
The problem was that the setpoint triplet is reset when the navigation
mode changes. So in this case, the triplet is reset when we switch from
takeoff to loiter which can happen before reaching the actual takeoff
altitude.
The fix is an ugly hack to prevent the reset in the case of takeoff to
loiter. A better solution would be to remove the general reset and have
all navigation modes do the proper resets themselves.
This hotfix should however be lower risk.
* Updated and expanded batt_smbus to work with bq40z50-R2. Expanded battery_status.msg. Fixed mavlink_messages.cpp temperature, added commented out expanded battery_status.msg parameters for future mavlink expansion.
* Changed errx to PX4_ERR
* Added PX4_ERR returns
If the GPS driver was used on another port (e.g. TELEM2), it would get
stuck in a `write` call and not return anymore. Disabling flow control
fixes that.
CPU usage is unchanged.
- move to ModuleBase
- strip down to PWM 8 and 16 modes only
- remove all dead code
- implement missing pwm ioctls (current value, rates, etc)
- default rate 50Hz -> 400Hz
When the timer callback is called at a higher rate than the logger can
execute the main loop (which is never the case under normal conditions),
the semaphore counter will increase unbounded, and eventually lead to
an assertion failure in NuttX.
The maximum semaphore counter is 0x7FFF, and when the logger runs at
default rate (3.5ms), the logger task must be blocked for 0x7FFF*3.5/1000
= 114 seconds continuously for an overflow to happen.
I see 2 cases where that could happen:
- the logger execution blocks somehow, or busy-loops in an inner loop
- a higher-prio task runs busy and hogs the CPU over a long period of time
On the Intel Aero and probably also other specific platforms
the first measured voltage values despite connected battery are unuasable.
The solution here is to start filtering and determining warning
only after a measurement above 2.1V was received.
This prevents the autopilot from sending an invalid unix timestamp.
Usually, if no time is set yet by a GPS, the date is somehow set
to 2000-01-01, therefore we can ignore anything earlier than 2001.
Roman