I did flash the pixhawk via USB, and the beeping stopped. QGC could see it then and I started the sensor calibration, but then QGC crashed. I switched back to tether connection, now QGC no longer sees the vehicle. Beeping is back, but pixhawk’s lights are blinking in the post-flash manner.
@schoonerlabs - Just updated the video stream bitrate to work better on Windows and added the “flash.py” script to allow flashing the Pixhawk remotely without a direct USB connection.
Richard,
Okay. That’s interesting. I would try power cycling the ROV and trying that again. If it crashes consistently let me know.
-Rusty
Well at least the beeping has stopped! I connected to the pixhawk via USB again, reflashed, and went through all of the calibration and setup tasks aside from testing the motor directions. QGC crashed several times during this process but recovered and hadn’t “forgotten” anything after each restart. Powered down, reconnected tether (and USB cable between Pi and pixhawk) and… QGC gets video but does not see the vehicle! I’m gonna go fuel up my chainsaw.
Richard,
Hold off on the chainsaw for a few minutes 
What version of QGC are you using? The version name/number is shown in the top bar of QGC.
-Rusty
QGC Development HEAD:531b9ac 2016-10-03 17:02:15 -1000
Alright. Haven’t tested the calibration process in a while but that should be the most up to date version. The next thing you can check is to start an SSH session and enter the following command:
sudo screen -r mavproxy
That will reenter the “mavproxy” terminal session and you should be able to see if the Pixhawk is communicating in there. Please paste the printout from that. You can type Ctrl-A D to disconnect from that terminal or cycle the power.
Sorry you’re going through so much trouble here! Hopefully we’ll get it figured out soon.
-Rusty
Well how do you like that? This time I powered things up and QGC saw the vehicle! I tested the thrusters and they worked as expected. I’ll try a few more on/off cycles tomorrow and if everything goes well take it for a swim in the pool.
Nice! Hopefully it stays that way. Sounds like there could be a loose cable or something
-Rusty
Some interesting findings today. First, several uneventful power-on and connect-up cycles- QGC saw the vehicle right away. Then, several cycles like I’ve been having- power on to vehicle, video makes it to QGC but it doesn’t see the vehicle. While this has been going on, I got a putty SSH session going. As I was typing the screen command you suggested, putty froze. I noticed the video stream also dropped out from QGC in the background. I looked at my topside Fathom-X board and saw that its link light was out. Link light on the vehicle’s F-X board was still lit. By the time I looked back, the topside board’s link light was back on and video stream returned. This has happened several times in the past 5 minutes. I powered down and checked on the vehicle’s F-X board-- the LX200v20 module is kinda loose. The strip of pins is soldered solidly onto the LX module, and the row of sockets on the host F-X board is soldered solidly on it, but when attached the combo is just loosey-goosey somehow, much different than my topside board. Could be our prime suspect! Anyway, once I finally managed to run that SSH command, here’s the output I got:
[ first a bunch of space, then the following ]
Using MAVLink 1.0
Using MAVLink 1.0
Connect /dev/ttyACM0,115200 source_system=255
Failed to load module: No module named terrain. Use ‘set moddebug 3’ in the MAVProxy console to enable traceback
Failed to load module: No module named adsb. Use ‘set moddebug 3’ in the MAVProxy console to enable traceback
Log Directory:
Telemetry log: mav.tlog
MAV> Waiting for heartbeat from /dev/ttyACM0
Then it sat there for maybe 10 minutes before quitting and going back to the SSH prompt.
‘Connect /dev/ttyACM0’ means that it sees the pixhawk is physically connected to the usb port. At this point, it should immediately receive a heartbeat from the pixhawk. If mavproxy gets stuck at this point, ‘waiting for heartbeat’, try a full power cycle (power to BOTH pi and pixhawk). Do you have any other devices connected to the raspberry pi usb ports?
-Jacob
Have done several full power resets, nothing else plugged into the Pi besides the pixhawk. Only thing that changed since yesterday and this monring’s successful sync-ups between vehicle and QGC was physical-- yesterday and this morning the vehicle was sitting on a chair (because I was doing a USB flash of the pixhawk). This afternoon, I moved the vehicle back to the floor, and the video-but-no-pixhawk connection business resumed. Loose connection somewhere seems very likely!
Hi Richard,
Sounds like you may have a bad Fathom-X board. When they’re working properly the link light should be solid all the time. I believe it lights up even if there’s nothing connected to the Ethernet port as long as the boards are connected.
Shoot me an email at support@bluerobotics.com and maybe we can get you a new one to try out. Don’t want this to be a headache for you!
-Rusty
Hi All
Things are going much better-- my '2 has been for a swim in my pool a few times with no leaks and things working pretty well! As seems to be the norm for me, I do have some puzzling issues:
- I've gone through the joystick calibration in QGC a few times (I have a wired Logitech F310) but still end up with forward/reverse corresponding to left/right on the left stick, and strafing left/right to forward and back on the left stick. Up and down work great on the right stick, but yaw rotation behaves weirdly... sometimes the ROV seems to be moving alot of water but not really moving, sometimes the direction of rotation reverses, most of the time yaw movements are sluggish at best, but once in awhile they are as snappy and precise as I'd expect. Something definitely amiss there.
- I configured things as shown in the setup manual, but I get no camera tilt action. Lights work great.
Glad things are going pretty well. I can help figure out these remaining issues.
-
Did you follow the instructions for joystick calibration on the ArduSub site? It has to be done a bit differently than QGC currently guides you to do. We are working on resolving that, but for now you have to do it backwards. Here’s the instructions if you haven’t seen them: http://ardusub.com/initial-setup/#joystickgamepad-calibration
-
As for the yaw behavior, make sure you have the motor directions set properly as well. Instructions for that: http://ardusub.com/initial-setup/#configuring-motor-directions
-
Can you show me a screenshot of the camera setup page? Also, which channel is the camera plugged into? And, did you leave at least one of the red 5V wires attached in the servo plugs to power the servo?
-Rusty
Hi Rusty,
Thanks for checking in.
- Yes, I've done the calibration as described three times, same result. I've attached some pictures showing how QGC understands my joystick at the moment: left stick up = pitch up, left stick right = roll right. Yet when the vehicle is in the water, the left stick controls are 90 degrees off: strafe is up/down, fwd/back is right/left on the left stick.
- Aside from the 90 degree off situation described above, motor directions seem fine. Fwd/back, strafe and up/down work great, and yaw works pretty well some of the time, and it's the "some" that's really puzzling. Sometimes I'll push yaw left, and the vehicle rotates left (counter clockwise viewed from above). I'll stop, then push yaw left again, and this time the vehicle rotates to the right. More often, the vehicle just seems to be throwing alot of water but not doing much rotation.
- Camera setup screenshot attached. Not 100% sure about the whole channel thing... that's done in MAVlink to simulate RC radio equipment, right? I don't think I modified anything regarding channels, just followed the instructions, and the lights work fine, which seems like a similar arrangement, just Ch9-to-RC7 instead of Ch10-to-RC8. Re: the 5V servo wires, I did as the instructions show, I clipped the middle 5V wires out of all but one of the ESC-to-pixhawk servo connectors and left the camera and light connectors unchanged, plugging them into RC 8 and 7 on the pixhawk, respectively.
Confirmed everything is wired up and assembled as shown in the assembly instructions.
Hi Richard,
Okay, thanks for the detailed description. I think I see what’s going on here. I don’t you’ve gone through the motor rotation direction steps yet (see here). This needs to be done when you first set up the ROV. It looks like a few of your motors are spinning backwards, which is switching the forward/strafe axes more-or-less, but it’s causing some funky behavior when you yaw.
Regarding the camera, it looks like you’ve got the output channel set up for “Channel 10”, while the servo is plugged into “Channel 8” on the Pixhawk. You can either move the servo plug to “Aux 2” (which is “Channel 10”) or change the output on the camera page to “Channel 8”. That should fix it.
The “Input Channel” is actually the control signal for the camera. I see how that’s confusing.
-Rusty
Ahhh I get it now. I tricked myself into thinking that because I’m putting together a BlueROV2 and chose “vectored” for the frame design in ArduSub and put everything together properly, I didn’t really need to check and set those motor rotation directions. That and that things seemed to work reasonably well as-is. Will do that step properly and set the camera to Ch8 and I’m sure all will be well. Thanks for the help and your patience Rusty!
Richard - great! Your case was particularly confusing because it almost worked right. Most of the time when a motor is spinning the wrong direction it’s pretty obvious! You just happened to have the right combination!
-Rusty