After several successful test flights, I am excited to let you all know that I have modified the ArduCopter code to run on the BlueROV. The flight modes supported are acro, stabilize, altitude (depth) hold, and land (surface). Acro works, but needs some tweaking, the other flight modes work beautifully.
Right now, the code requires an external pressure sensor MS5803 to be connected via I2C. This can be modified to allow acro and stabilize modes only.
The code runs with a modified version of the bluerov ros package.
Lots of useful telemetry is provided through APM ground control station software, which can also be used to modify many parameters on the flight controller.
Anyone who is interested in using this should keep in mind that this code an experimental proof of concept. Take appropriate measures to operate safely and be prepared to react to unexpected behavior. Let me know, and I will help you get set up.
The guys at bluerobotics are working on making similar modifications to the pixhawk/linux apm code. This implementation will be more fully featured and refined, and more parameters useful for an rov application will be introduced.
Here is some video from testing yesterday. One of the motors seems to be making an awful sound intermittently. They all appear to be in good working order after inspecting them. Let me know any thoughts on what might be causing that.
That looks great Jacob, thanks for sharing! It looks nice and stable and keeps an even depth under water, well done. Now you need to go explore something!
Cool! Just a bit of feedback for you guys who are tweaking the code:
"Auto head" is a very useful feature if you can add it (ie. heading hold/autopilot)
Although it looks cool to have the ROV zipping around quickly, it makes flying in close quarters difficult. Having some sort of thruster gain control is highly desirable.
Both of these features are supported. The controller sensitivity can be adjusted in the ground control station gui. The vehicle maintains it’s heading using the onboard imu and compass. If’ the heading is perturbed by a current or bump or something, the vehicle will correct until it is back to the desired heading that was last commanded by the pilot.
Edit: Actually, there is nothing in place right now to scale forward and strafing motion, I’m looking in to how to do that. Thanks for the suggestion!
Thanks for sharing Look super stable .Can you send me your setup .I am thinking what controller should I use for 6 motor blue robotics set up . I like the idea of the APM . Do you use any telemetry for your screen ??
What, in particular, would you like to know more about? These videos were taken with an apm 2.6 and raspberry pi controlling the ROV. However, Blue Robotics, and myself, have since moved on to the pixhawk for further development.
I use an xbox360 controller, a logitech f310 should also work.
There is a lot of telemetry available such as attitude, depth, voltage, inputs/outputs and many, many parameters of the system that you can adjust onscreen while the ROV is running in the water.
Very impressed by your videos. I would like to pursue a similar system… but didn’t want to use the raspberry pi UDP method…due to streaming video latency…
Questions:
How did you deal with the pixhawk safety switch?
check my conceptual block diagram… would it be compatible with your px4 code?
Are you using the bluerobotics thruster configuration?.. I had thought to arrange 4 thrusters like an X quadcopter… and 2 others for fwd/rev and yaw.
I don't know how long the signal wire from the rc transmitter can be (I'm guessing not 100's of feet), but what you can do is connect your rc transmitter to a laptop, and use qgroundcontrol to relay the rc transmitter commands through the rs485 interface
I am using the BlueROV developer kit with three vertical thrusters, which gives full control over roll/pitch and yaw, as well as forward/backward, left/right, up/down. Your configuration is cool, you will have to make a new motor configuration to support that setup. Also you will not have the ability for side to side motion (strafe).
Andrew & Jacob … Thanks for the responses. I plan to acquire a tether that will allow me the option of going either route… so the RPI & UDP will be the backup plan if I fail. My diagram failed to indicate a ppm line driver at the surface end… once I have sufficient tether, I will confirm ppm. telemetry & video links over suitable distances before developing software changes to suit this approach. John
If you want to input ppm, there shouldn’t be anything to change in software, it will work. The only thing to change is the method of arming, as the craft will start moving as soon as it’s armed with the usual method of holding the throttle/yaw stick in the bottom right. But that is a very simple fix, and you can always just click in the gcs to arm it instead.
