My software adventure keep continuing. I flashed the companion image used Etcher and it completes fine, but now the Raspberry Pi has a solid red light and doesn’t seem to be able to find the Pixhawk. The weird thing is that it was working fine a few days ago with the exact same companion images. I did double check that the USB cables are plugged in and I didn’t see any loose connections anywhere.
Is there a BlueROV2 specific troubleshooting checklist anywhere so I don’t have to spend hours looking through Raspberry Pi troubleshooting guides?
That’s normal, and indicates your RPi has a stable power supply (it starts flashing if the voltage drops too low). There’s a green light beside it which is on when there’s SD card activity ongoing
The “Opening /dev/serial/by-id/usb-ArduPilot_Pixhawk1_270043001451373232393438-if00 at 115200 bps” is actually from ~/companion/tools/ping_enumerator.py trying to find Ping devices, hence the ‘Unable to identify device’ message afterwards (this could definitely be made more obvious so I’ve raised a GitHub issue for it here). This actually indicates that the Raspberry Pi has a connected Pixhawk device that it knows about, so if anything indicates things are working correctly on that front.
Have you tried connecting to it with QGC, and/or seeing if the Pixhawk1 comes up in the “Detected Devices” in the companion web interface System page?
Thanks. The limited research I had done indicated that the red light was a bad thing and was probably either a power problem or boot device problem.
My main problem right now is that I can’t connect to the ROV. The web interface doesn’t connect, I can’t ping 192.168.2.2, and QGroundControl can’t find anything. I will do some more troubleshooting after I get home from work today. The tether interface is set to 192.168.2.1 as required.
The big blue light on the Pixhawk is flashing and I remember it being solid right after bootup, but I could be remembering wrong. I never really paid too much attention to the lights.
My main guesses for that would be either network settings (possibly set for an incorrect ethernet port/device) or maybe firewall (less likely since that should only block QGC, not the companion web interface), although if you haven’t changed anything on your surface computer since it was last working then it would be odd if one or both of those had changed (unless it happened in an update?).
When I power mine up the big light flashes yellow a few times quite fast, and then starts steadily flashing blue. That light has some quite complicated options - seems like it flashes blue while disarmed and with no GPS lock, and is solid blue while armed and with no GPS lock, but it also has several other possible states it can provide info about.
It seems like it was booting fine and it just takes about 5 minutes for the webpage to be available due to how slow the tether network or something else is. It used to take about 10 seconds.
I would like to see an in depth troubleshooting guide on the normal vs abnormal conditions, or at least update the troubleshooting guide to include all of the small things like the lights and beeps. I’m realizing now that I’m not sure about those things since I didn’t pay attention to them when the ROV was working, and now it’s making my troubleshooting harder. For example, It’s easy to miss that a tiny LED isn’t lit when it’s so small that I wouldn’t notice it unless I know beforehand that there is supposed to be a flashing light there during normal operation.
Definitely not normal to take 5 minutes - we’d normally expect around 30 seconds from power on for companion to boot successfully, at which point QGC should display the camera feed and start connecting to the pixhawk, and the web interface should be available. It’s best to open a new browser tab when connecting to the web interface.
I’m currently doing a relatively in-depth review of our documentation to identify missing or outdated information, and working on adding to and fixing that to improve the user and developer experiences - this is useful feedback. Some of the physical status indicators are documented (e.g. beeps for ESC connections and valid input/stopped signal in the Basic ESC learn tab), but I agree that it’s somewhat fragmented and could be made clearer with a more detailed walkthrough of a ‘normal startup’ or similar.
I expect that historically the various status LEDs of the Pixhawk and Raspberry Pi haven’t been in our documentation partly because they’re external products that have their own documentation, but perhaps mainly because the issues people tend to have most frequently aren’t indicated by those LEDs. From what I’ve seen so far the issues are more likely related to incorrect device connections or software settings, which can only really be debugged by connecting to the companion computer (via the web interface or ssh), or checking computer network settings and firewalls and the like.
That’s not to say the LEDs and their meanings aren’t useful though - they play a part within the larger task of making sure things are working as expected. I’m thinking a walkthrough of standard checks could include both physical and software-based indicators, and possibly include links or collapsible sections describing how to detect and fix abnormal behaviour.
