Copter-4.6.0-beta4 released for beta testing!

rmackay9 · February 21, 2025, 11:51am

Thanks @xfacta for that correction, the parameter is indeed ARMING_NEED_LOC. Sorry, the change originally added it to ARMING_OPTIONS but eventually we made it a new parameter.

Gregor_Enz · February 23, 2025, 10:34am

How i do , to have quick tune on RC channel?? i have H743, whitout SD Slot, exist a dokumentation, i not found nothing
thanks

xfacta · February 23, 2025, 11:47am

I can only see where Quicktune (C version) applies to Plane, not Copter.
As far as I can see Quicktune for Copter is still only available in LUA scripting.
Well in fact the code looks common, but there’s no Aux switch option for Copter, only Plane.

Ferrosan · February 23, 2025, 7:48pm

Hi @rmackay9 , had a bit of a hard time today with my trad-heli. Was doing fpv so at first I didn’t have a clear clue of what was going on. Initially, I saw severe tail oscillations due to main motor ESC going on/off randomly, managed to land without issues. Tried again couple more flights, one was ok the subsequent flight issue happened again, but I was hovering low altitude without goggles, so no scary moments .
There is this message popping up “internal errors: 0X4000020” , but haven’t had time to dig it up more.
This is not a new build, I only recently updated flight control (previously had a Matek 405 WMN- now upgraded to MAtek H7A3) and installed DJI-O4. History with previous flight control has no issues record, same general setup.

I can send DF log privately.

Paul_Paku · February 23, 2025, 8:04pm

A straightforward question: is it correct??
Hello strings repeats few times on boot.

23.02.2025 20:54:45 : MicoAir743-PPM 003E0047 3133510E 35313933
23.02.2025 20:54:45 : ChibiOS: 88b84600
23.02.2025 20:54:45 : ArduCopter V4.6.0-beta4 (6416da18)
23.02.2025 20:54:45 : Frame: QUAD/X
23.02.2025 20:54:45 : RCOut: PWM:1-4 PWM:7-10
23.02.2025 20:54:45 : MicoAir743-PPM 003E0047 3133510E 35313933
23.02.2025 20:54:45 : ChibiOS: 88b84600
23.02.2025 20:54:45 : ArduCopter V4.6.0-beta4 (6416da18)
23.02.2025 20:54:45 : Frame: QUAD/X
23.02.2025 20:54:45 : RCOut: PWM:1-4 PWM:7-10
23.02.2025 20:54:45 : MicoAir743-PPM 003E0047 3133510E 35313933
23.02.2025 20:54:45 : ChibiOS: 88b84600
23.02.2025 20:54:45 : ArduCopter V4.6.0-beta4 (6416da18)

Adam_Borowski · February 23, 2025, 8:27pm

I tested LD06 lidar support, and… it does not work. The only message is basically PRX1: No Data.
Also checked with 4.5.7 and it works with this version (obviously with some issues that are in 4.5.7 release) so this is not hardware/wiring issue as this is exactly the same between versions.

rmackay9 · February 24, 2025, 1:45am

Hi @Paul_Paku,

Those message are the “banner” which is printed each time something downloads parameters from the vehicle. So, no problem I think

rmackay9 · February 24, 2025, 1:54am

Hi @Ferrosan,

Thanks very much for testing and reporting back. So these two internal errors are:

0x4000000: mem_guard
0x0000020: panic

The 330 line number just points to the panic call found here. I’m actually quite surprised that a panic could be called from our flight code on a real vehicle.

I’m sure we will want the onboard logs if you can provide them.

I’ve added this to our 4.6.0 issues list.

FYI @tridge @bnsgeyer @tpwrules @peterbarker

rmackay9 · February 24, 2025, 1:58am

Hi @Adam_Borowski,

Thanks for the report. I wonder if you could provide an onboard log?

I’ve added this to our 4.6.0 issues list and I hope that @peterbarker who has recently done some work with this driver.

tpwrules · February 24, 2025, 2:05am

Can you replicate this on the bench? Mavproxy should be able to show the panic message if you are plugged in over USB. It looks like it is happening during boot anyway.

peterbarker · February 24, 2025, 2:21am

I’ve just re-tested locally here following the instructions in the Wiki (LDRobot LD-06 Lidar — Copter documentation) and my copy of the device here is working as expected.

Please check the contents of @SYS/uarts.txt - does it show a large amount of data flowing in on the UART the LD06 is connected to?

We should probably also see if somehow we are running devices from different manufacturers speaking a slightly different protocol.

This is the bottom of my unit:

Adam_Borowski · February 24, 2025, 7:34am

My actual device is LD19, but I verified it has exactly same protocol as LD06. Also fixed the driver myself in 4.5.7, but PR dropped as there was already some fix for this in review and I created it to 4.5 instead to master.

obraz

@SYS/uarts.txt shows

UARTV1
SERIAL0 OTG1  TX =  416776 RX =    8199 TXBD= 15758 RXBD=   309 FE=0 OE=0 NE=0 FlowCtrl=0
SERIAL1 UART7 TX*=  464673 RX*=       0 TXBD=  1329 RXBD=     0 FE=0 OE=0 NE=0 FlowCtrl=0
SERIAL2 UART1 TX =       0 RX*=  214000 TXBD=     0 RXBD=  8091 FE=0 OE=0 NE=0 FlowCtrl=0
SERIAL3 UART2 TX*=    1540 RX*=  181420 TXBD=    58 RXBD=  6859 FE=99 OE=0 NE=117 FlowCtrl=0
SERIAL4 UART3 TX*=       0 RX*= 4733135 TXBD=     0 RXBD=   327 FE=0 OE=0 NE=0 FlowCtrl=0
SERIAL5 UART8 TX =       0 RX =       0 TXBD=     0 RXBD=     0 FE=0 OE=0 NE=0 FlowCtrl=0
SERIAL6 UART4 TX = 1731084 RX =       0 TXBD=   495 RXBD=     0 FE=2 OE=0 NE=0 FlowCtrl=0
SERIAL7 UART6 TX =       0 RX =     133 TXBD=     0 RXBD=     5 FE=342 OE=0 NE=0 FlowCtrl=0
SERIAL8 OTG2  TX =       0 RX =       0 TXBD=     0 RXBD=     0 FE=0 OE=0 NE=0 FlowCtrl=0

What concerns board log - not sure if that is what You have in mind:

24.02.2025 08:21:12 : PreArm: PRX1: No Data
24.02.2025 08:21:12 : PreArm: GPS 1: Bad fix
24.02.2025 08:21:12 : PreArm: RC not found
24.02.2025 08:20:41 : PreArm: PRX1: No Data
24.02.2025 08:20:41 : PreArm: GPS 1: Bad fix
24.02.2025 08:20:41 : PreArm: RC not found
24.02.2025 08:20:10 : PreArm: PRX1: No Data
24.02.2025 08:20:10 : PreArm: GPS 1: Bad fix
24.02.2025 08:20:10 : PreArm: RC not found
24.02.2025 08:19:40 : PreArm: PRX1: No Data
24.02.2025 08:19:40 : PreArm: GPS 1: Bad fix
24.02.2025 08:19:40 : PreArm: RC not found
24.02.2025 08:19:27 : Frame: QUAD/X_REV
24.02.2025 08:19:27 : IMU1: fast sampling 8.0kHz/8.0kHz
24.02.2025 08:19:27 : IMU0: fast sampling 8.0kHz/8.0kHz
24.02.2025 08:19:27 : RCOut: DS300:1-4 PWM:5-13
24.02.2025 08:19:27 : MatekH743-bdshot 00370018 3233510F 35343832
24.02.2025 08:19:27 : ChibiOS: 88b84600
24.02.2025 08:19:27 : ArduCopter V4.6.0-beta4 (dbb9b75f)
24.02.2025 08:19:27 : Frame: QUAD/X_REV
24.02.2025 08:19:27 : IMU1: fast sampling 8.0kHz/8.0kHz
24.02.2025 08:19:27 : IMU0: fast sampling 8.0kHz/8.0kHz
24.02.2025 08:19:27 : RCOut: DS300:1-4 PWM:5-13
24.02.2025 08:19:27 : MatekH743-bdshot 00370018 3233510F 35343832
24.02.2025 08:19:26 : ChibiOS: 88b84600
24.02.2025 08:19:26 : ArduCopter V4.6.0-beta4 (dbb9b75f)
24.02.2025 08:19:26 : Frame: QUAD/X_REV
24.02.2025 08:19:26 : IMU1: fast sampling 8.0kHz/8.0kHz
24.02.2025 08:19:26 : IMU0: fast sampling 8.0kHz/8.0kHz
24.02.2025 08:19:26 : RCOut: DS300:1-4 PWM:5-13
24.02.2025 08:19:26 : MatekH743-bdshot 00370018 3233510F 35343832
24.02.2025 08:19:26 : ChibiOS: 88b84600
24.02.2025 08:19:26 : ArduCopter V4.6.0-beta4 (dbb9b75f)

Adam_Borowski · February 24, 2025, 8:04am

I did some quick testing and…
after reverting latest commit


SHA-1: 3e2428334b23f051c1e93bf4674f0e8429f20323

* AP_Proximity: correct length sanity check

the length field is actually the count of 3-byte data elements

it works fine again.

Ferrosan · February 24, 2025, 11:27am

Hi @tpwrules , unfortunately I was not able to reproduce the issue while on bench- if i were I certainly would of caught and report the issue before going into flight testing session.
It also actually does prevent arming once it’s tripped (tested this after landing).

I didn’t have that feeling, the message appeared also in the goggles well after I did take-off and climb-out. The thing is, according to the experience I’ve had so far, it seems to happen randomly.
@rmackay9 I will send you logs once back from work, this afternoon.

tridge · February 24, 2025, 8:55pm

please send them to me too

peterbarker · February 25, 2025, 1:44am

Great stuff, thanks for investigating!

OK, so it does seem that we have a problem here, as this sanity check passes on my LD06 - and removing the patch stops my device from working!

I’m quite sure we need a sanity check in here, as we’re working out how many bytes to read into a packet based off data straight off the wire.

The devices are kind of one-way, and there’s no identifying packet. Two options I can think of:

try to auto-detect based on values in the length field
add a separate proximity sensor type, so we have one for LD06 and one for LD19
check to see if we get a packet length of 47 in either case

The separate sensor type would be the cleanest. The last one is just nasty.

Thoughts?

rmackay9 · February 25, 2025, 2:04am

Hi @peterbarker,

thanks very much for the investigation. I vote for the auto-detect based on the first length value received, maybe spit out a send-text to say which one we’ve detected and then finally update the type parameter description to include LD06 and LD19.

Adam_Borowski · February 25, 2025, 6:51am

I wonder if You can paste few uart frames from Your LD06, I can do it for my LD19. We can check what is the difference here. According to every piece of documentation I found they should be identical.
Seems internaly my is also LD06

Wait… aren’t they identical? Exactly same markings on PCB

Adam_Borowski · February 27, 2025, 1:28am

I think I mentioned that before, but…

Caddx GM2 - connected with uart, initialization waits 60s from FC startup, not sure why. Before that time gimbal seems to be useless.

Second issue - gimbal position set by RC channel as Mount1Pitch is refresh about at 1Hz rate regardless of control type - angle and rate are the same.

rmackay9 · February 27, 2025, 2:24am

Hi @Adam_Borowski,

Thanks for the report on the CADDX gimbal. I’ve added this to the 4.6.0 issues list so that it won’t be forgotten.

I haven’t seen this issue myself but I use the GM3 so it’s possible that there is a difference on the gimbal side. Of course you’ve updated the gimbal since it was delivered? It needs to be running version 3.4