@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
1 Like
I’ve just released plane 4.2.3beta3. This is a minor stable release with a few new features and bug fixes. The changes from beta2 are:
- OpenDroneID improvements
- added --enable-opendroneid configure option
- added --enable-check-firmware configure option
- reverted notch filter changes from beta3 due to issue on some aircraft
- enable OSD menus on KakuteH7
- added prearm checks for rangefinder pin conflicts
- added diagnostics for scurve internal error
- allow absolute paths for linux boards in param defaults
- fixed AIRBRAKE rc option warning
I expect to release 4.2.3 within the next few days. Test reports would be most welcome!
1 Like
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
I have just released plane stable 4.2.3. This is likely to be the last stable release before we release the first 4.3.0beta.
The changes since 4.2.2 are:
- added OpenDroneID support
- enable OSD menus on KakuteH7
- added prearm checks for rangefinder pin conflicts
- added diagnostics for scurve internal error
- allow absolute paths for linux boards in param defaults
- fixed AIRBRAKE rc option warning
- fixed notch filtering ordering issue on loss of RPM source
- fixed Lutan EFI update serial flood
- fixed --upload to work on WSL2
- allow INA2xx battery to init after startup
- fixed healthy check on battery monitors to check all enabled monitors
- added Pixhawk6C and Pixhawk6X support
- fixed alignment of QRTL start in fixed wing circle landing approach
- added Foxeer Reaper F745 support
- added MFE PixSurveyA1 support
- fixed combination of waypoint passby with acceptance distance
- cut throttle on ICE stop when armed
- added ICE option for starting when disarmed
- zero VFWD integrator on ICE override in quadplanes
- don’t failsafe when in fixed wing landing sequence with RTL_AUTOLAND
- improved handling of overshoot in VTOL landing
- improved choice of target airspeed in VTOL landing approach
- improved ICM42xxx filter settings
- allow for faster sample rates on ICM42xxx
Many thanks to everyone who tested the beta releases.
Happy flying!
9 Likes
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.
1 Like
@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
Automatic Landing too short:
What do I have to change when my my automatic landing approaches are too short. Slope seems to be OK, but Tecs.hdem seems to be unreasonable during landing sequence (seems to me, tecs controller wants to go steeper than required to meet the targeted landing point). Please find the logs attached here: Logs_AutoLand
Thanks for looking at it.
Cheers
hi @tridge
i was trying to connect RFD 900x modem On CUAV V5+ running on AP 4.2.2
RFD modem connected on Telemetry 1 port with below setting
SERIAL1_BAUDRATE = 115
SERIAL1_PROTOCOL = 2
my RFD radio setting as below :
when i try to connect with mission planner at initial stage its getting data for just 2 sec and after that it wont get any data as link quality also keep decreasing up to 9% but still no luck connecting.
but as i can see the radio LED’s both radios working correctly. Finally No luck to get connection.
but same RFD 900X modem i had tried with Arducopter 4.2.3 on CUAV Nora+ with same setting and same wiring, its connecting and reading the autopilot data (only thing is its also went up to 20% signal quality after getting connection its start reading and while its keep increasing signal quality up to 98% after some time ).
i have taken video of both Arduplane and Arducopter how its reacting while connecting to mission planner RFD 900x modem connecting issue - Google Drive
I also tried this setting on Flight controller that BRD _SER1_RTS,CTS parameter to 0
and tried SERIAL1_PROTOCOL = 1 (Mavlink1) no luck.
please kindly look into this issue and give me solution.
I have flown VTOl today and need Little tuning to get better flying.
Any how i have noticed 3 issue :
1.Land disarm delay default timer was 20 sec …but this one i have reduced to 5 sec but it doesn’t work as expected.
Either VTOL land by QRTL or QLAND the land disarm delay is doesn’t work at 5 sec…its works after 16sec only disarmed.
I have configured ARM_Rudder = 2( can arm or disarm)
It only disarmed when in QHOVER mode and not in QRTL or QLAND by RC stick.
2.when i flown in fixed wing mode loiter or Guided mode trying to fly at some altitude like from 100m to 200m.
It was climbed upto 210m and then slowly coming down to 195m and later it settled to 200m.how to reduce this overshoot in altitude and get stop in desired altitude at first attempt.
3.loiter radius was set to 200m but when it flown in loiter mode i seen that in HUD screen it was around 260m below mode indication.
Note: WP_radius was set at 60m …it may be added up with WP _ Radius?
I’m trying to trace the PID control changes between Plane 4.0.x and 4.2.2. It is clear that the fixed wing plane PID changes occurred during 4.1.x and I have found the conversion calculator for that.
However, it appears that the quad plane PID control also changed between 4.0.x and 4.2.2, but I can’t determine when or how to convert between 4.0.x and 4.2.x.
Edit: this is assuming the quad PID control changed, as there are significant changes to the QuadPlane PID value ranges that put my 4.0.9 values out range for 4.2.2…
Hi Rolf,
how did you build the version for F405-WING with LUA?
If it’s done manually in hwdef.dat - could you post the file here?
I’ve a Sailplane only with GPS (no Compass or other external sensors) where there should be enough free memory for lua-interpreter.
Hi Willy,
I hope not inadvertently given the impression of being able to run LUA scripts on an F405. I also have LUA scripts running only on the F765 and H743. Hope I didn’t make a typo somewhere.
Rolf
It seems the developers are working on a minimized configuration especially for 1MB FCs. So I had the impression it’s still available.
Building a small Sailplane version only with GPS and soaring leaves 285072 Bytes blank - that should be enough for scripting :o)
BUILD SUMMARY
Build directory: /mnt/volume_nyc3_01/custom/base/tmp/plane:MatekF405-Wing:71828602e5eda0c68743352c1e8edd8af6a542a5:7298a57836b151b2f2fb6c9321cd9eaa/MatekF405-Wing
Target Text (B) Data (B) BSS (B) Total Flash Used (B) Free Flash (B)
bin/arduplane 697168 788 130368 697956 285072
it might be enough flash, but you won’t have enough ram on a F405. Lua is memory hungry
Thank you for the clarification @tridge , that I haven’t been aware of. So Scripting on F405 will never be possible, if I understood right.
So my PR Relocate mission 0.1 by WillyZehnder · Pull Request #21363 · ArduPilot/ardupilot · GitHub for relocating a mission still makes sense.
@Mark_Rosser Hi I have been facing a similar issue as you in the attached post link.
I wanted to know if you had set the params brd_pwm_vol_sel and Slew params before you changed this wiring and routing.