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.
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.
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 )