PreArm Internal errors (0x100000) l:967 flw_of_ctr

Blue Robotics Software QGroundControl
1

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

2

Hi @septtr, welcome to the forum :slight_smile:

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)

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.

4

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

5

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

6

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

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.

7

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.

8

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 :slight_smile:

9

:+1:

10

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

1 Like
11

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

1 Like
14

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.

1 Like
15

This happened to me 3 times today - I guess it was never ironed out with software updates? Only happened when disarmed then attempting rearm while submerged.

IMG_0291
IMG_02911920×1440 164 KB

16

Hi Elliot, Have tried williangalvani’s method as you suggest and still encounter this issue when re-arming underwater

17

Hi @3dMB,

Can you confirm which ArduSub version you’re running? I’ve been told the pre-arm prevention shouldn’t happen in the current stable, but it may also help to try the latest beta, which has had some optimisations to reduce the loop timing.

If you’re running BlueOS and have a Navigator flight controller then it may also be impacted by heavy running processes, so it might be worth checking the CPU usage of your Extensions and/or the BlueOS core services.

18

Everything is on latest version.

Yesterday I tried a Windows laptop as opposed to my regular MacBook Pro and no re-arming issues occurred, so maybe something todo with the MacOS version of QGC?