I solve it, I don’t know exactly why, but only a single port accepted to be activated as a trigger for the camera, which was AUX6, all the other AUX or MAIN did not accept it.
The configuration I used was simple,
CAM_TRIGG_TYPE = 1 (Relay)
RELAY_PIN = 55
SERVO14_FUNCTION = -1 (GPIO)
VTOL Landing Changes
The quadplane changes are focussed on two issues that have come up for users. The first is overshoot in VTOL landing. With previous releases if you had a significant overshoot of the landing point (for example if you had a VTOL_LAND very close to the previous waypoint) then the VTOL landing code would handle it very badly and actually fly away from the landing point for some time until the position controller unwound its buildup of target acceleration. The new code has special overshoot handling for this case. You will get a “VTOL Overshoot” message on the GCS and the aircraft will slow down then yaw around to face the landing point before proceeding back to the landing point at a speed limit of Q_WP_SPEED. It will yaw to keep the nose into the wind while moving back to the landing point.
The second key change is the choice of when to start VTOL control on the landing approach. The new code adds some more margin to start VTOL control sooner, which makes overshoot less likely.
The beta also adds a new arming check to ensure the distance from the previous waypoint to a VTOL_LAND is at least 75% of the calculated distance needed for a smooth stop (based on Q_TRANS_DECEL). This is to prevent users having a set of waypoints which lead to a large overshoot.
The final VTOL landing change is to suppress failsafes while you are in a landing sequence with DO_LAND_START. So once the series of waypoints following a DO_LAND_START has started any RC or GCS failsafes are ignored, allowing the landing to continue without forcing a go-around.
VTOL Land Airspeed
This release also changes the airspeed used for the approach to a VTOL landing if you have not specified a TECS_LAND_ARSPD. The airspeed used will be half way between ARSPD_FBW_MIN and TRIM_ARSPD_CM, so that the aircraft does slow down during the VTOL landing approach. Setting a TECS_LAND_ARSPD overrides this with a specific airspeed target.
Fixed Wing Approach Fix
The VTOL land option which uses a fixed wing approach followed by circling the landing point to estimate the wind then turning towards landing into the wind has been fixed to handle the case where the circling radius is smaller than the distance needed for the VTOL landing. We now ensure that we do turn towards the landing point before we transition, so we don’t end up trying to transition while at 90 degrees to the landing direction.
ICE Changes
The second significant set of changes is for ICE setups, where you control an internal combustion engine.
The first ICE change is to ensure you have zero throttle when you disable the ICE subsystem with the ICE control RC channel while armed. Previously we relied on the user having an ignition cut to kill the engine, and the throttle could still be active due to integrator buildup. The change is to help users without an ignition control channel, such as EFI systems that use zero throttle to kill the engine.
The second ICE change is a new ICE_OPTIONS bit to allow starting of the engine while disarmed in MANUAL mode. This can make for safer startup procedures as it ensures that VTOL motors cannot start even if you accidentally change flight modes or get a failsafe while waiting for the engine to startup.
ICM42xxx Filter Changes
The filter configuration on the ICM42xxx Invensense IMUs has been improved to better match the filtering we use on other IMUs. I’d be interested in feedback from users flying with these IMUs if you notice any issues with the new settings. It should be a significant improvement.
Happy flying!
Hey,
I have a Quadplane VTOL with 4.2.2 Firmware and I have been facing an issue when I try to land. Plane basically begins airbraking within the range I roughly calculate with Q_TRANS_DECEL but after airbraking for some time, one of the motors stops producing thrust (for one time motor stopped fully, the other time I could observe that motor was at least spinning after the fall). I did not have an issue like this with 4.1.7 firmware and I have flown it many times. First time it was the front left motor and for the second time it was front right motor. I checked electronics and wiring seems like it does not have any problem. It looks like ESC de-sync issue from the logs. My logs are nearly the same with @Mark_Rosser just like his motor PWM outputs mine have the same changes. I have seen that Mark has a grounding issue but seems like mine is not a grounding issue.
Can anyone give me an explanation or clarify what is happening after changing to 4.1.7 to 4.2.2 that triggers to stop the motor.
More information on the OpenDroneID support will be published later today.
Happy flying!
Hi Trkv,
My fault was a faulty ESC. Nothing to do with the firmware upgrade. After repairing the ESC it works fine in a flight test. Follow tridge’s advice and see if you can duplicate the fault on the ground with the motor test. Upgrade to the latest firmware 4.2.3 lots of trans and landing changes ( see Tridge’s release notes above )
Hey Mark,
I tried Tridge’s advice but I could not duplicate the issue, motors and ESCs both worked without any problem. @tridge do you have any idea what might be the problem?
I have tried ArduPlane 4.2.2 with CubeOrange with 2 different VTOL planes. Both had a problem during landing. For once it was front left motor which stopped and for the other it was front right.
Here are my logs,
Front Right Failure:
https://drive.google.com/file/d/1nie1ACMuYf4ql69mg49OKAZD3DeVGDDu/view?usp=sharing
Front Left Failure:
https://drive.google.com/file/d/1c_mO40yqgyp18QHezxRo8C8APWMDB278/view?usp=sharing
As pixhawk 4 is stopped (I use them in 2 different gliders), I would like to purchase a pixhawk 6.
My configuration is : 3.7 m glider (6 servos+prop)
Not professional use
Do you advise pixhawk 6c or 6x ?
Thanks
Adolfo
Hello.
As shown in the image below, when I try to upload Plane4.2.3beta2 to Pixhawk6X, I get the error “Error: Firmware not suitable for this board fw:10053 - board53”.
How can this be resolved?
I would be happy if you could tell me.
Best regards.
@tridge
Sorry for the repeated question.
When I tried to upload the ArduPlane 4.2.3beta2 firmware that I built from github master to CubeOrange, I got the error “ERROR: Firmware not suitable for this board fw: 10140 - board 140”.
Also, even if I upload ArduPlane 4.2.3beta2 from the beta version of Mission Planner as shown in the image below, the same error is returned.
How can this be resolved?
I would appreciate it if you could tell me.
Thank you.
the problem is you are using the “ODID” firmwares, these are OpenDroneID firmwares with board IDs that deliberately don’t match the normal board IDs. They are examples for US vendors preparing for the RemoteID requirement for vehicles sold after 16th September
Please use the firmwares without ODID in the name
I expect to release 4.2.3 within the next few days. Test reports would be most welcome!
Thanks tridge. In the future I’ll know better
@tridge the 4.2.3 beta 1 shows BATT_MONITOR > 24 as Fuel Level Analog. But the complete parameter list does not include the documentation for the same. could you please shed some light on it.
TIA
Many thanks to everyone who tested the beta releases.
Happy flying!
I recently has some RC decoding issues that were fixed by a power-cycle. Autopilot was a CUAV V5+ running Plane 4.2.3. RC receiver is an RX6R connected via SBUS and to a serial port for yaapu telemetry.
Tlog only, since I (thankfully) noticed the issue before arming and have LOG_DISARMED =0. Issues start at about 11% when the RC transmitter is turned on. Much of the time is spend with only the mode switch (ch5) being moved and sticks neutral, yet channels 1-4 are at fixed non-trim values. Channel 5 should get all the way up to the 1800s (mode 6) as I sweep the mode switch while debugging, but it doesn’t. The channel output percentage on the Taranis moved as it should.
After a reboot, everything worked normally. This flight is the second half of the attached tlog.
I suspect I had this happen once before to a different, but nominally identical aircraft several weeks ago running 4.1.7, but I dismissed it as a one-off and don’t have the log. In this case I scrubbed the flight once I noticed the mode changes. This suggests it’s not a hardware failure problem.
@Chris_Heintz what happened was it mis-recognised your SBUS as DSM initially.
You can use the RC_PROTOCOLS bitmask to set what protocol decoders to allow. Setting RC_PROTOCOLS=8 will mean just SBUS
