My ROV will arrive this Monday! (yay!)
Can anyone provide a build of materials for the ROV Control?
ANY suggestion will be appreciated. I want to get this up and running fast!
I just purchased a Raspberry Pi B+ with camera.
Should I get the PixHawk, or APM or ???
Thanks in advance!
Presently I believe that the software package is designed to work with the APM2.6.
I think it’s time to put together a roadmap for the BlueROV software and electronics moving forward. Our basic plan is to write the majority of the code on the APM so that it can act as a standalone ROV controller or in tandem with the Raspberry Pi for more advanced features.
I’ll add a link here to a separate post about the roadmap once we put that together.
I have modified the ArduCopter-3.2.1 code for the APM2.x to implement stabilization instead of just passing through controls as in the bluerobotics fork. I just uploaded to a board today, and the results are promising… it appears to work. So far I have the ACRO and STABILIZE modes modified. Next up will be depth hold, and I also want to do a mode to maintain a constant height above bottom.
I still need to test it in the water to tune the control loops and to find the proper motor mix.
I think that using ROS on raspberry pi and offloading control to the APM is a very decent solution. I plan on using the RC_OVERRIDE message through mavlink to inject the rc signals. Without the pi, it will be more complicated to get the rc signals from topside into the APM.
The unfortunate thing about the APM2.x is that it is no longer supported or sold, you can only get clones. I got an “APM2.8” on EBay, but it came without a compass on the board, which is not necessary, but will help with control and navigation. They have moved on to PixHawk 32bit platform. I have also modified the PixHawk code. I’ll get a Pix and see how that goes.
The APM code is huge and there are a ton of checks and balances that may need to be addressed. I think I have modified the major points, but I am going to sift through everything to avoid unexpected behavior.
The apm code is in ArduCopter-3.2.1 branch, I will be modifying heavily in the coming weeks and modifying the ros package to choose flight modes.
How many Thrusters does you modified code control?
Does it provide for lateral movement as well as yaw?
How do you propose to implement depth control?
The code is configured for the bluerov, with 6 outputs.
I have 6 input channels
3 to control attitude,: roll,pitch, yaw
3 to move laterally in the body frame: move forward/backward, up/down, strafe.
the inputs are mixed with stabilization control and sent to the motors.
Depth control will be a modification of the current alt_hold mode, I first need to integrate support for MS5803 pressure sensors.
This is fantastic! This is very similar to what we are planning to do with the APM. Very nice!
Most modern ROVs use 4 vectored horizontal Thrusters to move forward, backwards, in yaw and laterally and two vertical Thrusters for depth control.
Figured out how to pass through the mavlink connection through raspberry pi to ground control station running topside. the ground control station can be used to view artificial horizion, and all telemetry data in a ui. This also provides a ui to alter many, many parameters of the autopilot. This gui can be used concurrently with the rqt ui provided in bluerov-ros-pkg.
Tested working with apmplanner2 and qgroundcontrol on ubuntu 14.04 workstation.
Can you please provide a link to the configuration you are describing.
The apm code allows you to assign each motor a factor in roll, pitch, and yaw, and also mixes in the thrust, climb, and strafing control on top. I am developing this for a specific application, but I think that it is easily adaptable to any motor configuration. The apm2.x supports 8 different pwm outputs. You can send the same command to two motors with a y splitter servo cable. For more pwm outputs we will need the pixhawk.
I have successfully made modifications to the bluerov ros package, but I am not sure on how to keep that synchronized between git and the ros workspace, working on that.
I was testing before with a rc receiver connected directly to apm, now it’s working with xbox input through ros. Arms, stabilizes, disarms.
Attached is a top view of a standard vectored thrust ROV configuration.
How do you pitch? I think that frame could be adapted, do the motors move or are they fixed at those angles?
The Thrusters are fixed at 45 degrees to the ROV Chassis longitudinal axis, but can be adjusted to a shallower angle if necessary.
Pitch can be somewhat accomplished by using the horizontal Thrusters in combination with the vertical Thrusters.
Jacob and Tom,
Yeah - we’d like to support the vectored configuration in the future since it is the most common arrangement for work-class ROVs. With the vectored arrangement, you actually don’t have pitch control. It’s 5 degree of freedom. These ROVs have to be built in such a way that they are statically stable in pitch, usually by keeping the center of buoyancy well above the center of mass. A camera tilt mechanism is usually used for pitch control of the camera.
Jacob, are you running your modified ArduPilot code on an APM or PixHawk. I believe you started with the codebase after the point where the APM2.6 is no longer supported, correct?
I am running modified ArduCopter-3.2.1 on APM2.6. I have also made modifications to newer code that no longer supports APM, but I do not have a PX4 to test.
The vectored thruster configuration, and in fact, any configuration is adaptable. You just identify each thruster’s contribution to motion in each of 6 DOF.
My goal is to drop it in the pool tomorrow to test stabilization.
Hi guys, having just started back up in my rov build after stopping and moving on to multi-copters I have been flying using apm2.6 I would really like to use this or similar for control my layout is another common (2 thrusters for fwd/rev yaw 1 for lateral / strafe movement 1 for up/down), I also have noticed a good package for depth n heading sensor in open rov bolt on sensor, can this communicate with apm i2c then via Malink to osd? I am proceeding with control using my turnigy 9x then pwm to ppm converter for now.
The ms5803 sensor can be used for pressure sensing, and the pressure can be displayed in the gcs, I am working on it. Are you putting your rc receiver inside the rov?
You might want to reconsider using the APM2.6 because 3DR will no longer be manufacturing the APM2.6 and I consider them to be the only really reliable source of the APM2.6.
I would not trust my ROV at 100 ft in depth to a HK or other clone knockoff APM due to their poor quality control and possible use of counterfeit ICs.
Clearly there is movement towards the Linux environment for ROV control using the likes of the BBBMINI or the RPi with the PXfmini cape.
@jacob, the rc recever will be in the top control unit feeding into a ppm converter then down twp to another ppm - pwm converter to the speed controllers, I know this is not ideal solution but will start with this, good thing is all the mixing is done on the transmitter and is very easy to setup .
@TCIII, my HK apm has been working really good for over a year now, lot more to lose in the air than in the water, I am still open minded as to what to use for control, I originally had bought njs552’s Nick’s control system in kit form but struggled to get it to work with my limited soldering skills ( should have bought pre-made one but got frustrated and sidelined with work )