Do you know how long this bug has been present in Plane?
This would explain couple crashes i have seen.
Do you know how long this bug has been present in Plane?
This would explain couple crashes i have seen.
the home reset bug? I think since at least 4.0.
If you have the logs I could check. It will only affect takeoff if you have a Q_OPTIONS bit set to honor reference frame in VTOL takeoff. By default it always uses the current height as the takeoff start.
@Andrew_Tridgell
i had same gps problem with SKystars h743hd boards same as @makeflyeasy but yesterday i flew Arduplane 4.3.3 without problem with Speedybee F405 V3 board. Nothing happened negative.
All users are recommended to update to this release.
Happy flying!
Hi Tridge, Updated to 4.3.4 yesterday - however today at the field I was unable to arm my plane…usually I do this via the switch on the M8N GPS/compass unit but that method it no longer seems to work. I also tried arming from MP actions panel but it reported plane as armed and I wasn’t able to disarm and re-arm from there either. Tried rebooting FC (Pixhawk 6C) a couple of time - no joy. Any help much appreciated - parameter file here http://richardjcox.org/temp/params040323.params
Tridge, It’s all good now…I have set up to use right rudder to arm…now the M89 unit
switch arms all but throttle when GPS, compass fixes OK and right rudder on Tx
arms motor (following a radio recalibrate). Thanks again for all your development work.
@tridge
I ran into a problem with ArduPlane 4.3.2 today, I haven’t tested the latest 4.3.4 firmware yet.
question:
When I planned the waypoint, wrote it into the flight controller, and the ground station switched to automatic mode, the aileron and tail rudder turned to a certain angle, which was very strange.
After unlocking and taking off, the rudder returned to the center and returned to normal. I saw this output information in the log. My RCouts 2 and 4 are the tail and 1 and 5 are the ailerons.
Below is the log and video:
https://drive.google.com/file/d/13_YgHo1yAzoAjy-HGZ3n0i4Af73OcV2O/view?usp=share_link
https://drive.google.com/file/d/13VvUl6aASTYtsDHYLyWwlqa_sN6oWGsL/view?usp=share_link
On the ground this movement of the control surfaces is a normal behavior. Only in flight Ardupilot can execute the correct deflections of the control surfaces
@jreise-d
I have been using version 4.0.9 before. In AUTO mode, the state of the aileron and tail rudder remains in the neutral position before takeoff, which is normal.
@makeflyeasy this is very strange - the fixed wing desired roll and pitch rates are rising fast while waiting for arming in AUTO, but the desired roll and pitch angles are steady at the current angles:
@tridge
I use ArduPlane V4.4.0-dev; when the h16 remote control communication is interrupted, it will not recognize the sbus signal; only I restart the FC to recognize the SBUS; it is quite dangerous.
No, I don’t see anything. The desired angles could be lying to us, the show_vtol_view
function pics which attitude frame we log, so we could logging the VTOL angles but not using.
It is a suspiciously straight line to be coming of a gain, more likely to be a constrain somewhere.
All of you guys that work on these bugs are FUCKIN AWESOME.
This release has a single bug fix for a critical bug for anyone using bi-directional DShot on their vehicle. If using bi-directional DShot and the vehicle is running its motors when 32 bit microsecond time wraps at 71 minutes (or multiples of 71 minutes) then the bug that is fixed in this release has an approximately 1 in 3 chance of causing the motor to stop.
Note that the time is the time since boot, not the time since arming, so even vehicles flying for a short time could be vulnerable if they sit for a long time on the ground before takeoff.
Testers welcome! I expect to release the stable of 4.3.5 in the next few days.
Thanks for the quick fix.
This release has a single bug fix for a critical bug for anyone using bi-directional DShot on their vehicle. If using bi-directional DShot and the vehicle is running its motors when 32 bit microsecond time wraps at 71 minutes (or multiples of 71 minutes) then the bug that is fixed in this release has an approximately 1 in 3 chance of causing the motor to stop.
Note that the time is the time since boot, not the time since arming, so even vehicles flying for a short time could be vulnerable if they sit for a long time on the ground before takeoff.
This bug only affected STM32H7 based flight controllers, and only if bi-directional DShot was in use.
Where is SCR_ENABLE ?
I also don’t see APM>SCRIPTS folder
what flight controller are you using? Scripting is not enabled on boards that are low on flash or ram
Ahhh ok, I was testing a low on ram FC
Thanks
AP 4.3.5, PH4mini. At boot, I get this message:
`ERR Airspeed 1 not initialized, cannot call`
The aircraft has no AS sensor. I looked at ARSPD_*
parameters and noticed ARSPD_TYPE=1
. I set ARSPD_TYPE=0
and now I’m getting a different message:
`WRN No airspeed sensor present or enabled`
For reference, here are all my ARSPD_*
parameters:
ARSPD_AUTOCAL,0
ARSPD_BUS,1
ARSPD_DEVID,0
ARSPD_FBW_MAX,22
ARSPD_FBW_MIN,9
ARSPD_OFFSET,0
ARSPD_OPTIONS,11
ARSPD_PIN,15
ARSPD_PRIMARY,0
ARSPD_PSI_RANGE,1
ARSPD_RATIO,1.9936
ARSPD_SKIP_CAL,0
ARSPD_TUBE_ORDER,2
ARSPD_TYPE,0
ARSPD_USE,0
ARSPD_WIND_GATE,5
ARSPD_WIND_MAX,0
ARSPD_WIND_WARN,0