With the BlueRobotics team significantly lowering the cost of admission for marine robotic applications and 3DR manufacturing the highly successful autopilot, Pixhawk and Pixhawk 2, I'm of the opinion it might be time to do some research into an affordable AUV that is more than a "one-off" and doesn't cost $50,000.

I'm in the process of finishing up my OpenROV Mid-Sized Observation Class ROV and turning my sights toward other projects to meet requirements in the marine sector. Rusty and I have had intensive discussions on the future of area, and its very bright. Although I'm starting to gather parts for an ASV project, an AUV is definitely on my list for something that I can drop off the side of a boat and quickly run a transect scan on a designated target and return with photos of the seabed.

Looking into the problem, the biggest hurdle is a vessel knowing its position underwater, or at least a decent estimation to guide it. From reviewing the wiki on the APM Extended Kalman Filter, it looks like this would fit the bill in "plane" mode. The EKF takes measurements from all available sensors and can work out position and velocity, even without GPS for short periods. Obviously, GPS corrections will be required periodically to prevent the propagation of error from becoming too large.

Although we can use GPS, the INS and magnetic compass, possibly the optical flow sensor, we would still need a depth sensor, sounder and associated interfaces to Pixhawk. I'm not quite sure how to develop and interface those. Maybe substitute the depth sensor for the barometer? And an acoustic sounder for the LiDAR?

In the very least, I am confident I can get a hull put together using the BlueRobotics 4" enclosure at maybe 36" long, and then 3D print a bow and tail section with a GPS and communications mast. I was looking at using either the MARES or COTSBot for the basic design layout. I favor using thrusters over control planes because 1) we don't have a reliable deep actuator 2) the less moving parts, the better.

3691260877?profile=original3691260823?profile=original

Just some thoughts, as I'm not very far along designing this one yet, but I thought others might be interested or able to give their input. This intended to be a simple design that I place over the side, get it's bearings, dive, run a straight line about 10ft off the bottom, surface, get a fix, turn around and dive again to "mow the lawn". I've been working with others on imaging the seabed with Structure from Motion software to make up 3D models.

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • @Tom,

    Thanks! It's a little better than paint, and I'm glad the BR team made their models available...so much easier to visualize things.

    I have 3 of the T-200's with BlueESC's from the original KickStarter, so I'll probably just order one more and call it a day.

    @Rusty,

    Wow, I never thought of doing it like that! You are correct in that I am intending for this vehicle to have somewhat constant ahead motion. I would be concerned about it keeping an even keel for recording imagery and for the optical flow to register properly. I'd still like to see someone try it if they don't need to stay level. 

    Another option I am considering with the 4" Dome being released is something like this:

    3702147980?profile=original

    Anyone find that practical to have a viewport up front? I also haven't figured out a good mounting solution for the side mounted vertical thrusters to the 4" WTC. 

    Considering the batteries, I was thinking of something like these: LiFePO4 3.2V Prismatic Modules

    3702147937?profile=original

    Obviously I would need to tie more than one together in seines to get around 16V, but I like the even discharge rate, stability and safety. At least they will fit in the cylinder, on a 3D printed tray hopefully.

    • Admin

      @Keith,

      Just remember that when using the T100 Thrusters with the BlueESCs you are going to have two cables for each Thruster to deal with. This means that with only four Thrusters you will need eight cable penetrators for the Thruster power and control signals. The 4" Series End Plate has a maximum of 10 holes for cable penetrators and a pressure relief valve and you will be using nine of those holes for just four Thrusters. As you can see it will quickly become a rats nest of cables at the WTC rear end plate.

      To get around this issue I recommend that you use the Power and Signal Junction Boards that are supplied with the original KickStarter T100 Thrusters with the BlueESCs. The Junction Boards, once the assembled with their respective power and signal cables, can be potted with epoxy to make them waterproof. Each Junction Board will have four input cables and just one output cable reducing the number of cable penetrators to just two.

      Regards,

      TCIII AVD

    • @Tom,

      Thanks for the suggestion, that's what I was thinking of using. I would have plenty of 'wet-space' room in the aft tail cone to mount an encased power and signal board. They simplify the connections, but there will still be many wires back there I'll have to keep neat.

      Speaking of control signals, looking through the APMPlane set-up and parameters, I can't do skid steering right from the code. Below are the outputs from the Pixhawk:

      3702729532?profile=original

      I'm thinking I can disregard the Aileron channel and install a manual mixer from the outputs of the Throttle and Rudder. They have stock V-tail mixers out there, but there are also some products from M-tronics out there:M-tronics Tank Mixer

      3702729579?profile=original

    • Admin

      @Kevin,

      Here are the instructions in the ArudRover Wiki for implementing skid steering for the horizontal thrusters.

      Regards,

      Tom C AVD

    • @Tom

      I thought APMRover didn't have a Z axis involved? Nor the EKF. Unless I could somehow move the Rover skid steering code over to plane, but I don't think that's happening

    • @Darius,

      The EKF algorithm is already in the APM stacks. What is the UKF algorithm?

      @Tom,

      That was what I was thinking APMPlane might be for. It doesn't necessarily have to use the Rover code. Honestly, the vehicle is going to behave like a plane anyway, just in reverse. 

      I know I'm gonna lose the GPS, but the fun, technical side will be trying to keep the circle of error propagation as small as possible by using the extra sensors. I'm curious to see how well the optical flow sensor will do in shallow-ish water.

      The depth will have to be interfaced with the Pixhawk or other controller somehow. Position and Depth will have to feed directly into the autopilot so it knows when to dive or surface. There is a Depth I2C module out there and we can use an external barometer...so I haven't given up yet.

    • Admin

      @Kevin,

      That is correct, there is no Z axis involved, but ArduRover firmware fully supports EKF.

      Since this is an AUV and not a ROV, I would assume that you would use the skid steering function for forward, reverse, and right an left yaw and have either additional code or a dedicated depth control processor that would use the vertical thrusters to maintain a particular depth below the surface of the water.

      The navigation controller, like a Pixhawk, would be setup for the differential steering function to guide the AUV over its assigned course while, possibly, a dedicated depth control processor would maintain the depth of the AUV independent of the navigation controller. Otherwise you are going to have to have a custom version of ArudRover/Boat to manage your depth control with the vertical thrusters.

      Many AUVs have just one thruster for forward/reverse motion and do yaw steering with a rudder and dynamic depth control with diving planes. However, this just leads to more shafts and shaft seals to deal with.

      Without a GPS you are going to have to rely on your compass and IMU to maintain a given course.

      Regards,

      Tom C AVD

    • Could you tell me why do you prefer to implement EKF algorithm over UKF algorithm ?

  • Spent the better part of today working on designs in 3DS Max. I'm still pretty terrible in AutoCAD, but I'm working through the tutorials when I can.

    So from the first picture, you can see that my original idea of putting the vertical thrusters inside the nose and tail cones won't work. Already the thruster shroud pokes through a bit of the mesh on either side.

    3702146813?profile=original

    So on to the next revision. For this, I simply placed the thrusters on each end. I'm wondering how rigid this will be. 

    Below is the 36" version.

    3702146793?profile=original

    Below this is the 24" version. 

    3702146940?profile=original

    I'm not going for super maneuverability on this one as it's mostly going to be used for long transects, but I'm thinking the 24" might be a better start and expand into the 36" if need be. Thoughts?

    Also, any recommendations between the T-100/200 for something this size and power? I'll get into what I'm thinking for batteries in my next post.

    • Kevin,

      Looking good! Have you considered eliminating the front thruster? The back thruster alone will provide you with pitch control much like an airplane elevator. You would no longer be able to descend directly downwards, but I assume that this vehicle will usually have forward motion and could dive and ascend like an underwater glider. It might be necessary to add fixed fins on the side (near the CG) with this method.

      During descent, you would maintain forward thrust and then apply a small amount of upwards thrust to the rear thruster to point the nose downwards and descend.

      Thoughts?

      -Rusty

This reply was deleted.