Hi there. I have a BlueROV2. We haven’t had an issue with lights in the past, but I was trying to turn them on and got nothing. I was able to toggle the lights up and down in Cockpit (light percentage was shown at the bottom), so I know controller is working. I updated the firmware, and rebooted the machine, still nothing. I checked out the light settings in QGC and found that they are ‘disabled’. It doesn’t give me the option to switch it to a channel. I’m not sure what is going on. Anyone have ideas on how to enable the lights again? I already opened up the electronics enclosure and everything seems plugged in as it is supposed to.
Hi @coanderson,
The ArduSub firmware recently got some updates to how it handles lights configuration that QGC doesn’t know about. I believe QGC should still be capable of performing the old configuration approach, which the firmware should then auto-fix on the next reboot, but when that fix happens the QGC Lights page will again present the lights as not configured.
The joystick button functions have not changed, so as long as the relevant buttons are assigned they should still be able to control the lights, and the lights percentage should still be reported. If that’s working in Cockpit then it should also be working in QGC, but it’s possible your joystick configuration is not the same between the two software (which might be the actual cause of your issue).
Hi Eliot, this is good to know.
I need to clarify that the lights did not turn on when I toggled the light percentage up and down in cockpit. I can’t imagine that all four lights are broken.
Does this change your reply at all?
Hi @coanderson -
I think Eliot (and I) were going based off your statement here…
If the lights are’t working at all, can you share a screenshot of your PWM outputs page under Vehicle Setup in BlueOS? What ArduSub firmware version (and BlueOS version) are you using?
I had updated the arudusub firmware yesterday and this AM with no change in lights turning on/off (ArduSub version 4.5.7 and BlueOS version 1.4.2 ). I just went into BlueOS vehicle set up and it seems like the PWM outputs were not mapped correctly based on the link that Eliot provided, even though I recently updated and haven’t changed anything in the PWM tab. I went into the configuration tab and reset all parameters to default and now the lights work in cockpit!
My QGC keeps crashing so I haven’t been able to test the lights in that software (my cockpit is closed when I try to use QGC). I still have the version of QGC that is recommended in the software set up. Is that still the best version?
Thanks!
Updates always try to maintain previous user configuration where they can, so if you had previously changed the lights channel (possibly just while testing) then it may not have been set to the channel your lights were actually attached to, which would explain the behaviour where joystick button presses were reflecting in the autopilot’s reported lights level (which Cockpit displays), but the lights themselves were not lighting up (i.e. because the pin they were connected to wasn’t outputting a relevant signal).
Great to hear you’ve managed to resolve this 
That recommendation is just based off the last version we did extensive testing with before our development and maintenance efforts switched fully to Cockpit. It may be that QGC developers or contributors have updated some functionalities in line with more recent firmware updates, and/or it may be that there are new bugs or broken functionalities (especially where ArduSub is concerned) now that Blue Robotics is not actively keeping an eye on it - I really couldn’t say.
You can try a newer version if you want, in case it works better for you, but it may be harder for us to provide support if something doesn’t work as expected. From the Blue Robotics side we’re trying to make sure the BlueOS+Cockpit combo reaches sufficient feature parity (plus a bunch of improvements, of course) that we can stop recommending a particular QGC version at all, at which point we can update our setup guides to only use Cockpit, and QGC just becomes one of the alternative control station software that we don’t actively support.
Is there a reason you’re trying to use both? It’s unclear whether you’re trying out Cockpit to potentially switch, or have some reasons you need to keep using QGC for now, or just tried opening QGC when the lights functionality wasn’t working properly with Cockpit.
Good question. I was under the impression that all of the sensor calibration needed to be done in QGC – is that true? We were also using QGC because we have a waterlinked USBL and my coworker implemented NMEA data streaming from the USBL gui to QGC’s map so we could get a real time view of our rov position. Can that be done in cockpit too? If so, I might just switch over to CP fulltime.
Hi @coanderson -
QGC should be showing your ROV on the map without needing to implement anything - as long as the autopilot is properly configured to know its location from that USBL! Does it show on the map in the correct location when reviewing log files?
Cockpit does support showing the vehicle position on the map, if the same conditions are met… If you don’t have position in your logs, we could dig into your configuration further!
That should generally be possible through the BlueOS Vehicle Setup now, and I believe the intent is for any missing ones to be added in 1.5 (where they haven’t already).
Interesting! I get a bit confused on QGC vs cockpit. I downloaded a bin file from a previous dive we had with the USBL and in viewing it with plot.ardupilot.org I see depth and lat/lon data in it. I know MAVLink passes gps data to QGC, but you are saying that it also passes it to Cockpit and cockpit updates the rov position on the map automatically? I guess we’ve never tried that.
Our USBL is somewhere else now, but when I get it back I’ll do a test.
1 Like
Hi @coanderson -
Both programs are GCS solutions - ground control station software. They exist just to visualize the telemetry from the vehicle, and relay user commands.
The USBL should be configured so the location information is passed to the autopilot. When this occurs, when viewing the log at plot.ardupilot.org, you should see the path taken by the vehicle on the map - more than just having lat/long data…
If it is present, the vehicle should also be able to use position hold and guided/auto modes! It should also “just work” when it comes to viewing on the map in Cockpit - simply select the map view from the lower left!