Currently doing initial setup for my BlueRov2. When I follow the instructions to update the Ardusub firmware, the website returns “no data available” in the field where the latest stable configuration should be. Any ideas why this might be? Thank you!
Hi @marshall_lee,
Most likely there was also a notification in the top right corner, which would have said “firmware fetch fail” or similar. That can happen if there’s something preventing the firmware files from being found online, which could be from the ROV not being connected to the internet, or perhaps an issue with ArduPilot’s prebuilt firmware server.
Assuming you have an internet connection, it should generally work to try again a bit later, but if you want to investigate a bit more you can turn on Pirate Mode, go to the File Browser, and access the logs at var/logs/blueos/services/ardupilot-manager to see if it gives any more information about what happened / what went wrong 
Hi @EliotBR,
Thanks for the response. You were spot on, there is a notification that reads
FIRMEWARE_FETCH_FAIL <urlopen error [SSL] unknown error (_ssl.c:1129)>
I have a steady internet connection, but I’m not sure how to check if the sub itself is connected. Please let me know if you have any insight.
Hi @EliotBR,
I’m also having issues with the network speed test: it seems unable to compute an upload speed (but it was able to compute download speed). Further, the video connection that I see in QGroundControl is very choppy (I see a single still frame every 2 seconds or so, followed by a black screen that says “Waiting for video” briefly before I see another still frame). I’m not sure if these might all be intertwined connectivity issues, so I was hoping you might have some ideas. Thanks for the help!
Edit: I’m also unable to access the File Browser via Pirate Mode. I just get a spinning load circle for a while but no error messages pop up.
Edit again (sorry): I also found this in the QGroundControl console, which might shed light on the video connectivity issue I’m having, though I’m not really sure how to interpret it.
[E] at D:\a\qgroundcontrol\qgroundcontrol\src\Camera\QGCCameraManager.cc:245 - "Camera "H264 USB Camera: USB Camera" stopped transmitting. Removing from list."
[E] at qrc:/qml/QGroundControl/FlightMap/PhotoVideoControl.qml:434 - "qrc:/qml/QGroundControl/FlightMap/PhotoVideoControl.qml:434: TypeError: Value is null and could not be converted to an object"
[D] at D:\a\qgroundcontrol\qgroundcontrol\src\comm\UDPLink.cc:205 - "Adding target QHostAddress("192.168.2.2") 46618"
[E] at D:\a\qgroundcontrol\qgroundcontrol\src\Camera\QGCCameraControl.cc:831 - ""Could not save cache file C:/Users/Steve/Documents/QGroundControl/Parameters/H264 USB Camera: USB Camera_H264 USB Camera: USB Camera_000.xml. Error: The filename, directory name, or volume label syntax is incorrect.""
[E] at D:\a\qgroundcontrol\qgroundcontrol\src\Camera\QGCCameraIO.cc:327 - "No response for param request: "10094849""
[E] at D:\a\qgroundcontrol\qgroundcontrol\src\Camera\QGCCameraIO.cc:327 - "No response for param request: "10094850""
[E] at D:\a\qgroundcontrol\qgroundcontrol\src\Camera\QGCCameraIO.cc:327 - "No response for param request: "10094851""
[E] at D:\a\qgroundcontrol\qgroundcontrol\src\Camera\QGCCameraIO.cc:327 - "No response for param request: "9963776""
[E] at D:\a\qgroundcontrol\qgroundcontrol\src\Camera\QGCCameraIO.cc:327 - "No response for param request: "9963777""
[E] at D:\a\qgroundcontrol\qgroundcontrol\src\Camera\QGCCameraIO.cc:327 - "No response for param request: "9963778""
[E] at D:\a\qgroundcontrol\qgroundcontrol\src\Camera\QGCCameraIO.cc:327 - "No response for param request: "9963779""
[E] at D:\a\qgroundcontrol\qgroundcontrol\src\Camera\QGCCameraIO.cc:327 - "No response for param request: "9963788""
[E] at D:\a\qgroundcontrol\qgroundcontrol\src\Camera\QGCCameraIO.cc:327 - "No response for param request: "9963792""
[E] at D:\a\qgroundcontrol\qgroundcontrol\src\Camera\QGCCameraIO.cc:327 - "No response for param request: "9963795""
[E] at D:\a\qgroundcontrol\qgroundcontrol\src\Camera\QGCCameraIO.cc:327 - "No response for param request: "9963800""
[E] at D:\a\qgroundcontrol\qgroundcontrol\src\Camera\QGCCameraIO.cc:327 - "No response for param request: "9963802""
[E] at D:\a\qgroundcontrol\qgroundcontrol\src\Camera\QGCCameraIO.cc:327 - "No response for param request: "9963803""
[E] at D:\a\qgroundcontrol\qgroundcontrol\src\Camera\QGCCameraIO.cc:327 - "No response for param request: "9963804""
I think that’s a BlueOS frontend issue that’s been fixed in the beta releases but not yet in stable. This direct link should hopefully work:
http://blueos.local:7777/file-browser/files/var/logs/blueos/services/ardupilot-manager/
If there are permission errors, try removing everything after file-browser and reload the page, then click through the folders to the one you’re after.
Those tests are for the network speed between the vehicle and the topside computer, and are unrelated to internet speed. The download is from the vehicle, and upload is to the vehicle. They’re both important for normal communication (and a low download speed would be a potential reason for choppy video), but aren’t related to the vehicle’s connection to the internet (which is what matters when downloading firmware).
By the way, if your network speed is very low, and your order shipped in May or June this year, you may be running into this issue. Worth a check!
I brought up the failing firmware fetching issue internally and was told it’s possible our timeout is too short before deciding that the information was not available, because the ArduPilot servers can sometimes be very slow to respond, so we’re looking into improving that.
In the interim you may want to download firmwares directly from ArduPilot firmware : /Sub, selecting a valid one for your flight controller board (e.g. Navigator / Pixhawk 1), then using the “upload custom file” option to upload it to the vehicle.
Note that updating the autopilot firmware is only relevant if you aren’t already on the latest stable firmware. Currently that’s 4.1.0, and you can check your in-use version in QGC’s Summary Page, or in the General page of BlueOS >= 1.1 (currently only beta/master, next stable release should hopefully be quite soon).
Hi Eliot,
I was able to access the log file through the link you sent me. When I try to load the firmware in BlueOS using “Choose from Repository”, the log file shows the error attached in the text file. (It’s quite lengthy so I won’t paste it here). I am, however, running the correct version of the firmware (4.1.0), so this is not an urgent issue. Just figured you’d like to see the error for you own edification. Thanks for the help!
Error Log BlueOS.txt (13.0 KB)
1 Like
Thanks - I’ll pass that on to the software team in case it helps with their debugging
From what I’ve found, this could be related to a problem on the ArduPilot’s SSL certificate. Are you still experiencing the same problem, or was it gone?
I’m still having the same issue (same error code in BlueOS, can check the logger from pirate mode as well). One thing to note is that I did see the firmware dropdown read “searching for available firmware” before ultimately timing out, which is not a message I had seen previously.
Ok, that’s strange. You’re connected through wifi or theter? This connection has access to the internet? If so, could you provide a (complete) log from ardupilot-manager from a session where you’ve tried to update the firmware?
A simple way to test if you have internet connection is by using the version-chooser and seeing if it is able to find remote images there.
Yes, my computer running the BlueOS web interface is connected to wifi (I’m able to see images from version chooser). I’ve attached a full log in which I started up the vehicle and went to update firmware in BlueOS. Hope this helps.
Ardupilot Full Log.txt (27.8 KB)
Thanks, @marshall_lee! We are investigating this problem, but so far we couldn’t reproduce it.
One thing that was mentioned was that SSL certificates need the client to have the correct system time to work. Have you noticed if yours system time is correct?
Edit: we think we’ve found the problem. You can track the development on this here.