Good afternoon everyone. We have our BlueROV2 just about assembled, and I’m going through the final steps of gaining control over the vehicle.
For some reason, we do not have any vehicle control whatsoever. Let me show you what we’ve got.
System delivered in Summer 2016 with advanced electronics package.
Topside laptop is running Windows 8.1. QGroundControl can successfully pick up the video feed from the vehicle but there is no thruster control.
MicroSD card on Raspberry Pi has been loaded with the 2017-01-12-ardusub-raspbian.img, written with the Win32DiskImager software utility.
The PixHawk has been flashed via direct USB to the topside laptop using QGroundControl. I flashed the ArdSub-v2.px4 firmware to it.
When I power the sub, it beeps every 5 seconds (without stop). Running QGroundControl gives me video feed and also gives me compass and attitude display. However, if I run
sudo screen -r mavproxy
to see what mavproxy is doing, this is what we get:
And then it just hangs there. I’m kinda stuck at this point, and I’ve been reading through other posts here on the forums trying to find something similar…I’ve checked my connections, checked power, Windows firewall settings are open for me to run this software… Is there something flaky with how I have the Raspberry Pi set up to see the Pixhawk? The Pixhawk is the only component connected to a USB port on the Raspberry Pi.
Is it the motors that are beeping? If so, make sure that you have the signal cables for the ESCs plugged into the Pixhawk correctly (yellow on bottom), as shown below.
Hi Jeff,
I also had the problem that the motors beep every second and arming of the ROV was not possible.
The main LED of the Pixhawk flashed double yellow. I looked at this page Link and disable the pre-arm checks in the parameter section of QGroundControl.
After this small change everything works at my side as it should.
I’m almost embarrassed to say this…All of the signal cables are upside-down going into the Pixhawk (we bought the system but had a high-school senior do the assembly as part of a senior project)… I’m just trying to move things along by handling the vehicle programming.
Now I need to do some more wiring checks and also review what @sl13 wrote to double-check our boot sequence.
@jsnyder,
Attaching the ESC input cables to the Pixhawk upside down essentially connected each servo pwm output pin to ground which might have damaged the Pixhawk.
Regards,
TCIII AVD
Thanks guys. That was the critical issue. Funny how something so fundamental brings things to all-stop.
Now I’ve got to work on controller mapping via QGroundControl. What is odd is that we have the camera three-wire connector plugged into slot 8 on the PixHawk per the assembly instructions, and via QGC we can only control the tilt mechanism by adjusting the controller mapping to assign the function for lights dimmer and brighter.
I’m not sure if that is an error on our part, or just part of the command mapping between QGC and this firmware for the PixHawk. Additionally, we have no control whatsoever over the LEDs so we’ve got to try to tackle that. I double-checked the wiring on the Lumen LEDs (we have the 4-wire set) and on the boards in the vehicle they appear to be wired correctly. I’m going to try using a different hand controller and reloading QGC.
. I’ve done this numerous times myself, that’s why it occurred to me to check!