BlueOS faulty upgrade, reinstall Blueboat

Hi BlueRobotics,

I was updating BlueOS to version 1.1 (2 weeks ago) from factory setting because of the notification on the top main landing page of BlueOS. It did download and restarted. And then it the blueboat was beeping like it encountered somekind of error.

I did turn off and turn on the blueboat, but after the NavLight went Solid On, it won’t go to the slow pulse. From there on I cannot access blueos.local or I can access (base station wireless router) and (blueboat wireless router), but not the blueOS in raspberry pi.

How to overcome this problem?

Hi Blue Robotics,

I flashed the 16GB MicroSD Card with BlueOS 1.1.1 img as per the documentation below:

Plugged in the SD Card into the Raspberry Pi 4 inside the starboard hatch… turn ON the BlueBoat … wait ~5 minutes… and then i can ping … and then I am able to access the BlueOS through chrome browser on Windows 11.

  • I tried using 64GB MicroSD Card class 10, but it takes too long to do initial boot/expand, so I switch to using the 16GB that came with the BlueBoat (the docs says: It should take around 2 minutes for a 16GB class 10 SD card).

I am using BlueOS v 1.1.1 and tried to use the wizard to setup the BlueBoat, but stuck atStep 3. Customize, like in the printscreen below. I can’t click ‘CONTINUE’ button.

So I just continued with a good wifi connection to the Blueboat. And then updated the Autopilot Firmware chose Vehicle type : Rover and use Firmware STABLE 4.2.3… and then continue setup with connecting to QGroundControl. During vehicle setup at QGround Control chose Frame Class: Boat. And continuing on with Sensor Calibration (Accelerometer and Compass), Check Motor Directions, Calibrate the PowerSwitch, Controller Setup and Parameters backup… basic follow of the guide below:

And then at the BlueOS/Vehicle Setup click the ‘Load Default Parameters’. Out of 800+ parameters, failed to load 53 or 57 parameters. Everything seems OK, except for the Navlight Flashing Patterns.

At first boot, the Navlight was doing a solid ON, and then after… it is OFF… while the documentation layed out the flashing patterns of Navlight should be like in the table below:

The above table was copied from the guide below:

At this stage, how to make the Navlight Flashing Patterns normal again? And what about the default parameters that failed to load?


I’m having a very similar issue trying to reflash a blueboat, and can’t seem to find a stable version of blueOS and ArduRover firmware.

I’ve tried stable v1.1.1 of blueOS with v4.2.3 of Ardurover and tried loading the .params file via VehicleSetup in BlueOS but it fails to load all the NavLight (NL_) params.

I updated to Ardurover v4.4.0 and it appears to load a full set of params but there are no NL_ ones listed and the Navlight doesn’t work the way it did with the factory settings. this version of the firmware also fails to recognize the ping1D device which was working in a previous version.

Once version 4.4.0 of the firmware is loaded, there’s no way to step back to previous versions as the update from cloud fails and there doesn’t appear to be a way to either download versions of the autopilot firmware.

Can you recommend a fully functioning factory setup (BlueOS + Rover fimrware) for the blue boat and some steps to get there. I’ve spent a lot of time trying different configurations of BlueOS and firmware but cant seem to find combination that works. On another note, the configuration wizard seems to fail and never loads parameters for the blue boat.

Thanks in advance.

I’m in the same situation, I thought a simple reflash of BlueOS was going to be a simple way to get back to a clean install. I was having issues with a ping2 so wanted to rule out anything else I may have done recently.
But I now have BlueOS installed but it won’t run through the setup wizard and I now can’t get a decent version of Ardurover firmware loaded. Seems to fail everytime and often doesn’t even recognise the Navigator board.

Hi all - so sorry you’re having issues!
We’re aware of some bugs that are contributing to what you’ve all stumbled with, and have fixes that will come soon for the loading of the parameters via wizard, as well as loading of the autopilot versions available to flash. In the meantime, I have some workarounds for you:

For autopilot firmware, download the latest stable from here - note 4.4.0 should NOT be flashed at this time, it isn’t supposed to be an option yet!

For default parameters, download the default parameters file for BlueBoat from here, and from the Autopilot Parameters menu load the file. You’ll need to calibrate your accelerometer and gyroscope after this step.

Let us know if that lets you move forward. Sorry for the hassle, thanks for your patience and understanding!

Thanks for supplying the files Anthony but I’m still having the same issues when I try to lad the params file via the autopilot parameters menu. It shows 53 to go and then crashes which seems to be happening with others. See screenshot below.

I have been able to get everything up and going with the exception of the nav light. I’m running OS1.1.1 and Rover 4.2.3 and integrated a ping1D which does show up as a distance sensor in QGroundControl.

The autopilot parameters page shows 856 params.

Hi @Paul -
Would you mind updating BlueOS to V1.2 beta 2, and seeing if you still have issues? You could also try rein-stalling the autopilot firmware. Apologies!

Hi Anthony,

I upgraded the OS to V1.2 beta 2 as suggested and tried reloading the params file and still get the same error where 53 won’t load. I then manually upgraded the firmware to the stable 4.2.3 version you supplied a link to and retried the params upload and still get the same error. see screenshot

Ok, we’ve confirmed the issue is still present on v1.2 beta 2 - sorry for chasing the wrong path there. But I do have a fix for now!

In the file browser (pirate mode, left menu), navigate to this path: /configs/ardupilot-manager/firmware/scripts
Then put this .lua file there, but only after removing the .txt extension (necessary to upload to our forum.)
lights.lua.txt (4.2 KB)

Restart the vehicle and try to update the parameters - the issue should be almost completely resolved! You (might) have only one parameter fail to write - MOT_THST_ASYM - issues with the Navlight should be fixed. This parameter is only in Rover 4.4.0, which has been fixed and should be ready for testing - it means the boat can go 1.6x faster in forward than reverse and shouldn’t affect performance much. You can download this firmware directly here, it should be selectable in BlueOS easily soon.

Thanks for your patience!

p.s. - 1.2 beta 2 does have the fix for the system reverting to “factory” BlueOS, which can be quite annoying! You do need to Update Bootstrap after applying the update for this to take effect.

Hi Anthony,

Still having issues. Here’s the steps I took:

  1. Retrieved lua file and removed .txt extension.
  2. Copied it to /configs/ardupilot-manager/firmware/scripts (see screenshot)
  3. Rebooted system via Power/Reboot
  4. Tried re-loading params via AutoPilot Parameters/Load
  5. Showed 53 to load but failed as per previous error
  6. Restarted and tried loading params via Vehicle Setup/Configure -same error

I then reverted to OS1.1.1 and tried the same params load but that failed as well.
Is there something I need to do to get it to run the lua script?


Hi @Paul -
I’m unable to replicate that on the two Blue Boats I have with me- both fail with the script not present, but are ok once it is present.

Judging from my screenshot vs. yours , I attached a bad version of lights.lua! I’ve updated the link, apologies.

Hi Anthony,

SUCCESS! Yay. It must have been the different lua file.
Interestingly, the nav light starting working as expected before the NL_ params were loaded. The autopilot params list is now showing 908 entries in the autopilot parameters list. I’ll make sure to back that up this time. I didn’t notice that that was recommended until I fully rtfm’d the software setup after I bricked the factory settings. Oops.

On a couple of other notes, is there a way to manually check or control the light flash patterns via BlueOS or QGC? It’s currently doing a quick flash at about 0.5 Hz and I’ll like to cycle some of the other patterns.

Would you recommend I continue to use v1.1.1 of the OS or go for the 1.2.0 beta 2 version? I’m a little reticent to play around with the settings now that I’ve got it back up and running again. When do you think ardurover 4.4 will be stable for the blueboat?

Finally, now that I’ve got a ping1D sending mavlink depth data, I’m looking to also integrate a simple serial sensor as well, and have successfully setup the serial bridge via BlueOS but may have some questions about the integration steps to QGC. I think I’ll start a new forum thread for that and will try to document the steps so others don’t have as steep a curve. Is that the best way to go? Thanks again.


Hi @PaulBarter -
Woohoo! Glad that was it, sorry for the mistake.

Re: your questions -
I’m not familiar with how the blinking is controlled, but a quick glance at that lights.lua file indicates that it is the script the autopilot is using to handle the blinking. I’d imagine any modifications would start there?
The 1.2.0 beta 2, with bootstrap applied, fixes the annoying roll-back bug, so I prefer it. I’ve run some long, 6 hours missions with it recently without issue! I’ve not yet tried Rover 4.4 in the wild, but it is up and functional, and I flashed it to my vehicles yesterday.
A new forum post is a good idea, but when it comes to Bridges, QGC is not going to help you much I believe? Maybe if you can explain what you’re going for, in terms of user experience, that’ll help guide the conversation. If you want data from a serial stream alongside your video stream, the Cockpit extension is going to make this far easier and straightforward / supported! We are debugging some general issues with bridges at the moment, so if we run into problems it might be a bit before we can resolve them.
Thanks for sticking with the effort!

Thanks @tony-white,

I think I’ll stick with rover 4.2.3 but will apply the beta 1.2 OS and bootstrap it and report back how that functions just to finish off this thread.

In terms of serial, my original plan was to add depth via an NMEA 0183 smart transducer and I was able to successfully get a serial bridge established to that sensor on one of the navigator serial ports and see the NMEA sentences by running a python script that opened the UDP port from the bridge.
After that, I came unstuck because I allowed the boat to do a rover firmware upgrade (to 4.4) and have spent the last couple of days trying to recover from that. I’ll start a new thread for the serial integration.

I’ve loaded cockpit but haven’t had a chance to try it much yet. Any quick thoughts on how I’d display the ping1D data in cockpit? I can’t see much available in the configuration screen.



Hi Paul -
You should be able to use the very generic indicator widget in cockpit to show the rangefinder, this corresponds the ping2 measured depth. You could also use my Simple Survey extension as well, although embedding it within cockpit as an iframe will likely make it a bit tough to use.

Thanks @tony-white

Do you mean one of the regular widgets in the edit interface (as shown in screenshot)?
I don’t see a generic indicator in this list of widgets (nor in the mini widgets) and can’t see where the rangefinder would be referenced.

Cheers and sorry for being a pest today.

Hi @PaulBarter -
No problem!
It’s under mini-widgets:

Once you drag it out onto the interface, you can find it in the list of widges, and configure it with the gear icon.
It’s currently a bit of a pain to scroll through the variable list to find RANGEFINDER.distance, but this is how I configure it with icon and units / name:

And what it looks like on interface:

Also worth noting - you can configure QGC to display the same Rangefinder value in the black box at the bottom of the interface…

@tony-white is the gps issue I saw elsewhere fixed in rover 4.4. I’ll be doing all of the above tomorrow.
Cheers for you help working through these early day niggles.