While waiting for the thrusters to arrive I thought I’d make a start on the ‘brains’ and thruster control. So far all working fine in dry tests using the Bluerobotics ROS package with simple_pilot. Quick picture attached - still to fix the esc’s to the frame once thrusters are wired in.
Still not 100% set on the frame design, though keen to go with a vectored thruster set-up similar to TCIII as this appears to be the preferred layout for maximum manoeuvrability.
Next steps are to finalise a frame design and work on the code - though I found Rusty’s helpful kickstart on the thruster coding here: code
Currently researching options for fixing the corner thrusters to the frame e.g. directly bolting to frame strut, using S/S hoseclamps or building some sort of custom mount. Frame will most likely be PVC or aluminium tubing or a combination of the two. Any suggestions welcome.
Getting very excited now!
On a complete tangent - just got back from a business trip to Washington DC and managed to free a couple of hours to visit the Smithsonian Air & Space museum - very impressive! A great encouragement to keep tinkering with stuff. It’s a brave man who’ll come hurtling back from space in the attached.
Thanks for sharing. That’s a very artistic/professional photo of your electronics tray!
If you go with the vectored setup, remember two important things:
The center of gravity of the entire vehicle should be inline with the vertical height of the thrusters. If the CG is higher or lower than the thruster, then they will also contribute to pitch and roll motion and the vehicle will be less stable.
The center of buoyancy should be a few inches above the center of gravity for strong static stability. The basically means enclosures and buoyancy foam at the top, battery and heavy parts at the bottom.
The BlueROV with 6 degree of freedom thrusters has a relatively high CG that is inline with the forward thrusters. The center of buoyancy is also relative high and close to the CG, making it just slightly stable. We did that because it is a fully actuated 6DOF ROV and strong static stability would make it hard to perform 6DOF maneuvers.
What type of frame construction method are you planning to use?
Your comments regarding the BlueROV have got me thinking again about the potential trade-off between responsiveness and stability. I’ve looked at the BlueROV videos and the responsiveness of the 6DOF movements looks fantastic. Curious though as to how the BlueROV configuration performs with, for example, holding a reasonably steady position in a cross current?
I’m assuming software developments to take advantage of feedback from the IMU will help make marginally stable or even unstable configurations manageable as is the case with multiopters.
The feedback from the IMU makes a huge difference, but it means that your vehicle has to have a thruster arrangement for six degrees of freedom. As far as holding in a current, I suspect that a vectored configuration would work slightly better since it has more even thrust in each direction. The BlueROV would do well going forward, but not so well in strafe.
I’d be keen to add an a separate WTC to house separate batteries and sensors etc, so have been brainstorming ideas in sketch-up. These are really rough ideas, still needing the full CoG CoB calculations and the construction details worked though, but testing concepts.
The first would be to run a second WTC laterally as in ROV perp 1 and 2. This has the advantage of keeping the height relatively low.
The second thought is to run the second STC parallel to and below the primary WTC, with the lateral thruster at the bottom, adjusting the height of the thrusters to account for the lowered CoG. Starting to get quite tall. See ROV parallel
Third option is to run the lateral thruster between the two WTCs, something like central.JPG.
I’m sure there are numerous other options too - Anyone running a thruster config similar to BlueROV but with a second WTC?
A final option is of course to reconsider running two WTCs and put the effort into reducing the size of the electronics to fit a single WTC rather than trying to work through getting the ROV to work with two WTCs?
The thrusters arrived last night after a few extra day’s delay while they were held for import checks.
I potted the cables last night, so today was the first time the ROV had been in the water.
The good news:
The two WTC's have no leaks, everything is bone dry.
My buoyancy calculations were fine, the ROV is slightly positively buoyant and sits fairly flat in the water.
All thrusters/esc's are running great.
On the work to be done side:
I'm running the ArduSub code and the outputs to the thrusters are seeming a bit random. Particularly thruster 2 (same layout as the Blue ROV) which has taken to running at full thrust. I've double checked the motors are connected to the right outputs on the Pixhawk and tomorrow will check they're all spinning in the right direction, with particular focus on the two thrusters with reversed props.
I tried to compile the latest version of ArduSub but hit the error "*** No rule to make target /home/bluegs/ardupilot/ArduSub/config_channels.h', needed by/home/bluegs/ardupilot/ArduSub/AP_State.cpp.o'. Stop.", so will take a look at that tomorrow too.
First of all, the easiest way to detect if it is an esc problem or a software problem is to just plug a different motor into output #2 and see if that one spins at full throttle, too. If it does, it is something in software.
Second, make sure that your pixhawk is calibrated and level. Does the motor run back down or switch direction when you tilt the craft forward or sidways?
Third, make sure that you have the most recent changes pulled in. There have been some significant changes in the last week.
Fourth, you should make sure that you are building for the correct frame type. cd into the ArduSub directory and do:
‘make px4-clean’
this should fix the target error you have. Then to build do :
Looks great! I’d follow Jacob’s recommendations and also make sure that the IMU is calibrated to level. The vehicle will try to correct it’s attitude so if it thinks it’s tilted, the #2 thruster could stay at high throttle trying to correct.
Can you upload a log saved from qgc? A “telemetry log.” I think this is one off the sd card or dataflash of the pixhawk, which I have not figured been able to open and view yet.
No Mavlink file was saved from Qgroundcontrol using the dialog box that comes up when exiting Qgroundcontrol. Where do you normally take the log from? I couldn’t see where to analyse a log in Qgroundcontrol either?
Ok, I got an error the first time I tried to open your log in qgc, but I have it open now with no issues the second time I tried. In qgc go to one of the dropdown bars and pick show status bar. For me it is in View, but they recently moved it to File. In the status bar pick replay log file and it will let you browse for one to open.
