PreArm Internal errors (0x100000) l:967 flw_of_ctr

[septtr]

Hello,
I am getting this error continuously and cannot arm the vehicle unless I reboot it. Couldn’t understand the reason… Is there anyone out there to help about it…?

BROV2 Heavy Configuration
Pixhawk 1
ArduSub 4.1.0 Stable
Companion version 0.0.31
QGC v4.0.5 (I have to use this version because I use Ubuntu 18.04 )
WaterLinked UGPS and Waterlinked DVL Installed and Integrated

[EliotBR (Eliot)]

Hi @septtr, welcome to the forum

I’m not sure what’s going on there, although if there’s an error with pre-arm checks then I’d recommend you check that

1. your sensors are calibrated
2. your joystick is plugged in and calibrated
3. you don’t have irrelevant / unimportant arming checks turned on (in the Safety Setup page)

@septtr

QGC v4.0.5 (I have to use this version because I use Ubuntu 18.04 )

It’s also possible that QGC 4.0.5 is unable to properly handle ArduSub 4.1.0 since it doesn’t know that it exists, but if that’s the case I would expect the error to always occur rather than being fixable by restarting.

Are you able to try QGC 4.2.3? As far as I’m aware it should still work with Ubuntu 18.04 (it’s even targeted by CI), and there are open issues from people using that combo who aren’t saying that the whole program doesn’t work.

[septtr]

Hi @EliotBR
I realized that I have this Pre-Arm error if I arm the vehicle when it is not in manual control mode. When it’s in manual and if I arm, I have no error. If I chose, for example, ‘depth hold’ or ‘stabilize’ control mode first and then arm the vehicle, I have this error. Any idea about this ?

Thanks

[septtr]

Hello @EliotBR

1. All sensors are calibrated
2. Joystick is calibrated, all the motors are in right direction
3. I don’t have any irrelevant checks… In fact, I turned off most of them.

I installed QGC 4.2.3 but the error still pops out time to time. Any help would be appreciated.

Regards

[EliotBR (Eliot)]

I brought this up with the software team, and was told

@williangalvani

that is similar to an issue I’ve experienced in early Navigator development, [where] we were having very long loop times, [which] caused an issue here.

is_active_z() checks if the control loop ran in the last 5 [main loop iterations].

I think for debugging this, setting SCHED_DEBUG = 2 [(via the QGC Parameters page)] could help. It will output the control loop’s information every 10 or 20 seconds.

If that is the issue, reducing SCHED_LOOP_RATE could help [to resolve it].

It’s perhaps also worth noting that using both the Water Linked UGPS and DVL at the same time is an unusual combination, since the integrations (and devices themselves) haven’t yet been tested and optimised to work well together.

[Teggles (Terry Eglinton)]

I developed this error on the 3rd dive of the day! I was having trouble with depth hold, calibrated it no problem but as soon as I selected depth hold the ROV would dive to the bottom. So I carried on with the task manually. On the 3rd dive, change of battery and now I have the error. I will investigate further this morning.

[EliotBR (Eliot)]

Hi @Teggles,

I’d recommend making sure you’re on the latest recommended software versions. If that doesn’t help please try @williangalvani’s suggestion above

[Teggles (Terry Eglinton)]

[Teggles (Terry Eglinton)]

Changing the schedule loop rate to 250Hz appears to have solved the problem.

[septtr]

Thanks a lot … It looks the problem has been solved.

[elchinaslanli]

For my situation lowering closed control loop hertz (400 Hz to 200 Hz) did not solve the problem.

I also update the ardusub version from stable to latest beta, and problem no longer exists.

Thank you for tips.