I am trying to load the v2-6.px4 version onto my Pixhawk through Q Ground Control but between the Ardustack and Advanced settings box is a dropdown menu asking me to make a selection as the whether I want Quad, X8, Hex, Octo etc APM:Copter v3.3.3. I don’t get the plain menu option that Ardusub shows in its documentation so am unsure what selection I must make. Any ideas?
I am having to load the file on by plugging the pixhawk directly into my computer bypassing the Raspberry Pi and Fathom X board as for some reason nothing reaches by ROV through somehow being blocked by the topside ethernet connection or the set up at the ROV end. However, I am waiting to get support for BR on this and hope to resolve it soon.
You can leave the first dropdown empty and just check “Advanced Settings”, then choose “Custom Firmware File…”. At that point you should be able to choose an ArduSub-v2.px4 file from http://firmware.ardusub.com/.
It’s not possible to reprogram through QGC through the tether at the moment. It has to be done via a direct USB connection. We do, however, have a command line utility that will allow flashing through the Raspberry Pi. I can describe that in more detail if you’d like or you can read about it here: http://ardusub.com/raspi-setup/#flashing-pixhawk-through-ssh
Thanks for that Rusty. I now have the Pixhawk and Q Ground Control running smoothly with all motors configured and thrusting in the right order if I do it all through USB input directly from my laptop to to the Pixhawk. However, if I attempt to do it via an ethernet connection through the Fathom Xs and Raspberry Pi, Q Ground Control cannot see that there is anything there. I have the ethernet port configured, all firmware loaded and because I have 3 tethers, 6 Fathom X boards, 3 preloaded Raspberry Pi’s and 3 Pixhawks I have been able to test all possible combinations to eliminate the possibility of component failure. Any thoughts would be greatly appreciated.
Okay, it’s really helpful that you can eliminate a hardware failure! Have you set up your computer to have a static IP address of 192.168.2.1? That’s required for the Raspberry Pi to know where to send the data and video stream.
Yes, had done all that to no avail but have just changed ethernet cable from the Fathom X to my laptop and yes, Q Ground Control see the ROV. When I arm it, the vertical motors come on at some speed trying to make the ROV descend. I will try to recalibrate the Pixhawk unless there is another explanation you can offer.
First thing I would check is to make sure you’re using the daily build version of QGC. The “Stable” 3.0 version does not have all of the most recent updates for ArduSub. You can download the daily build here: http://ardusub.com/initial-setup/#install-qgroundcontrol
I’m guessing this is a joystick related issue and this will fix it. If you’ve already got the most recent daily build then we can investigate other possibilities.
<p id=“yui_3_16_0_ym19_1_1473755807701_3312”><span id=“yui_3_16_0_ym19_1_1473755807701_3534”>Hi Rusty</span></p>
<p id=“yui_3_16_0_ym19_1_1473755807701_3262” dir=“ltr” data-setdir=“false”><span id=“yui_3_16_0_ym19_1_1473755807701_3272”>loaded the latest daily q ground control build and the latest ardusub and re-calibrated the joystick.as soon as the ROV is armed, now all motors start at about half revs. toggling doesn’t do anything but changing the mode from manual to stabilise or depth hold escalates the revs on all motors substantially.</span></p>
<p id=“yui_3_16_0_ym19_1_1473755807701_3262” dir=“ltr” data-setdir=“false”><span id=“yui_3_16_0_ym19_1_1473755807701_3434”>earlier today, the motors all lay idle until throttle was applied so the current status is something if a backward step.</span></p>
<p id=“yui_3_16_0_ym19_1_1473755807701_3262” dir=“ltr” data-setdir=“false”>when the</p>
<p id=“yui_3_16_0_ym19_1_1473755807701_3312”><span id=“yui_3_16_0_ym19_1_1473755807701_3534”>Hi Rusty</span></p>
<p id=“yui_3_16_0_ym19_1_1473755807701_3262” dir=“ltr” data-setdir=“false”><span id=“yui_3_16_0_ym19_1_1473755807701_3272”>loaded the latest daily q ground control build and the latest ardusub and re-calibrated the joystick.as soon as the ROV is armed, now all motors start at about half revs. toggling doesn’t do anything but changing the mode from manual to stabilise or depth hold escalates the revs on all motors substantially.</span></p>
<p id=“yui_3_16_0_ym19_1_1473755807701_3262” dir=“ltr” data-setdir=“false”><span id=“yui_3_16_0_ym19_1_1473755807701_3434”>earlier today, the motors all lay idle until throttle was applied so the current status is something if a backward step.</span></p>
<p id=“yui_3_16_0_ym19_1_1473755807701_3262” dir=“ltr” data-setdir=“false”>I am not sure if this is relevant to the issue, but when joystick calibration is completed, the attitude controls are not centred as I would have though they would be-see attached tiff on previous message.</p>
<p dir=“ltr” data-setdir=“false”>cheers</p>
<p dir=“ltr” data-setdir=“false”>John</p>
<p dir=“ltr” data-setdir=“false”></p>
I loaded the latest daily build of q ground control and re-loaded the latest ardusub file and re-calibrated the joystick. when the ROV is armed, all motors start immediately at half revs. I am not sure if this is relevant, but on competition of joystick re-calibration, the attitude controls are not centred as I would have thought they should be.
it was happening in all modes but after unplugging it and allowing it to reboot several times it the problem disappeared. at the same time I had been unplugging and plugging in the joystick repeatedly and then q ground control suddenly showed all the joystick setting centred and the motors then responded properly from that point. I am not sure where the problem actually lay but possibly with a slight glitch with q ground control. Now the only remaining issues are no video signal and the ROV stays powered up unless I physically disconnect the battery.
Glad you got it connected now. For the remaining issues:
The ROV is powered on by the battery connection and there is no on/off functionality. We may make that available as an option eventually.
As for the video, what operating system are you using? We’ve heard reports of trouble with Windows 7 but success with Windows 10 and Linux/Mac. I would also suggest double checking the camera connections. If neither of those are the issue, then I can tell you how to connect to the Raspberry Pi and check for error messages.
Everything, including video is functioning perfectly now. It is testimony to a great design from you and your team that somebody with such limited knowledge such as myself can assemble it. Thank you very much for your patient guidance through the process.
no idea what was causing the video fail. it just spontaneously kicked in when I was plugging and unplugging my joystick trying to get q ground control to see it. now everything works fine so pool tests planned on the weekend and then sea testing after that. can’t wait!
QGC does not support hotplugging of the joystick as of now (this will hopefully be fixed in the near future). If you unplug the joystick while QGC is running, joystick input will hang until you exit and reopen QGC. To the same effect: You also need to be sure that the joystick is plugged in before opening QGC.
