Design Concept

Open questions will appear on this page for discussion. ย After consensus is reached (or after a long time with no discussion), the question will be moved to the resolved category along with its discussion.

Open Questions:

DQ2013-06-11a: Would it be most cost- and time-effective to design the system around an on-board smartphone that provides wireless communications, GPS, AHRS, camera, and computational functions, or would it actually be more effective to build it up from discrete processors and sensors?

Resolved Questions:ย 

14 comments on “Design Concept
  1. Bob Allen says:

    The questions in Phil’s last paragraph IMHO are on the money. Dependency on cell tower proximity for comms seems extremely limiting. All this talk about communication both while submerged and when on the surface suggests the adoption of some well defined use cases (mission profiles).

    For instance, I can see plenty of utility in a sub having _zero_ comms when under the surface, roaming far far away from land masses, and reporting in/uploading data only upon surfacing, no matter the data it’s collecting. Hell, a capable enough vehicle could be programmed to “follow” a pod of whales and report findings whenever surfacing. The photosphere is where recharging and comms (and retrieval) are easiest. Down below it’s all about collecting useful data.

    Those are my thoughts and you may disagree. But it sure would be nice to get past all the “it could be an elephant .. no wait, it could be a snake”. BUILD something already.

    The idea of piggy-backing off of Open ROV (or maybe “commandeering” an OpenROV) seems like a reasonable way keep it simple in order to get something happening.

  2. Pavlos Spiros says:

    Hi all,

    I just joined the group. Looking carefully on previous posts I would like to add some comments.

    An autonomous vehicle is a device which follows a predefined route or is generating a route as a result of sensor measurements. To implement each scenario you need proper sensors (ultrasonic sensors) to “see” in front of and under the vehicle. This sensors in accordance with a Inertial Measurement Unit and a well designed firmware will help the AUV to navigate automatically underwater.

    Everything is possible with or without a smartphone; you can launch an AUV even with an Atmega8 MCU. However first of all we need to define the specifications in more detail. For example if we have the requirement to stabilize the AUV in certain depths near the seabed then we need to put another sensor to measure the distance between AUV-seabed or to measure the “optical flow” from our heading sensor.
    Image processing through a camera is also possible and much cheaper but the visibility is dependent on weather conditions and the range maybe a few cm in worst case.

    In general, I think we can take OpenROV experience and add a low power processor-MCU to handle the peripheral modules, such as IMU, GPS, 3G. The only problem I can imagine is the cost of a sonar-like sensor.

    Waiting for your comments.

    • Phil Marcelino says:

      I agree with. There are going to be a few driving factors with this project. One is the cost of the components, while the other is going to be the amount of batteries that are going to be required to run all of this equipment which Thomas eluded to in another post.

      Once the project starts up again, all of these topics are going to have to be addressed. They’re not deal breakers, but there will obviously have to be some trade-offs that are going to have to be done.

    • Troy Barnhart says:

      I tend to agree with your last paragraph and I’ll be willing to take it one step further. The OpenROV electronics package is proven it can and does drive a vehicle underwater. What if instead of looking into reinventing the wheel so to speak we look more into building a “pilot” module for OpenROV that just handles the automation side of things? I am currently in the process of finishing my OpenROV variant and I have plenty of room in my design for extra sensors even another smaller PV if necessary.

  3. Jon Riley says:

    Apologies. Some of the answers to the questions I raised are already answered within the Design Goals section. Kind regards, Jon

  4. Jon Riley says:

    As a suggestion, and with love and kindness to all previous contributors, it may be wise to begin the journey with a functional spec and avoid the technology options a bit until there is a general specification agreeable to the connected community. If you want some suggestions on that let me know, otherwise I’m ok to read what you write. ๐Ÿ™‚

    Consider for example, that most of the features of the average smart-phone (e.g. network coverage, WLAN, GPS, bluetooth, etc) don’t actually work underwater (even if it is in a sealed lunch box ๐Ÿ™‚ ). Although the accelerometer may be useful and the compass might be useful too, the operating system is typically android or iOS and so would be problematic to adapt to a marine vehicle anyway.

    To help begin the journey with some basics, may I ask whether you have a typical mission (or mission parameters) in mind?

    To help with general bounds on the design, have you already arrived at dimensions for max-depth, volume, payload, power-density, max-speed, cruise-speed, variation in mass through the mission (mass depletion through consumption of fuels or discharge or payloads? vs mass increase through collecting samples etc?).

    Are there constraints on cost, size or any interfaces yet? Should we assume IP irrespective of the communications channel?
    How accurately do you need telemetry info (for example position, depth, speed, direction, previous waypoints?)

    Prior to the agreeable spec have you prescribed that the open auv would employ Linux on-board as the operating system anyway?
    I’d guess open means different things to different folks so worth clarity.

    It may help to consider Linux if the vision is for code-sharing in the community. If not then it may be worth considering how it might be possible if the community might wish to do so?

    The idea that it may also be possible to bring any number of hardware variants to use a common software library may be worthy of consideration in the early phase. Doing so could help simulation and testing of software (modules) for example telemetry, communications and control, sub defaults and fail-safe behaviours, sonar, depth sounder and audio dsp, propulsion control, guidance & navigation, buoyancy control, video image capture, filtering and forwarding, robotics and payload management, fuel/energy/power control – all of which could be developed and tested independently before the community even gets to the hardware.

    I hope this helps. If you disagree, then please politely contribute your views, since here is your chance to be heard. ๐Ÿ™‚

  5. Cecil Johnson says:

  6. Jordan Stanway says:

    What is the nominal mission for this strawman design? Is it running a lawnmower survey snapping photos? Is it doing YoYos to collect temperature and salinity transects?

    How long are the missions? How well does the vehicle need to know where it is?

    Just some questions to start with.

  7. Aaron Marburg says:

    Strangely, of all the benefits of using a smartphone, I’d think localization would be the least of your concerns, at least out here in the first world of unlocked phones. But a phone is compelling as it’s often cheaper and smaller than the dev board for the equivalent chip. Not to mention the second hand market. Perhaps we’re saying the same thing … a smartphone is a cheap way to get your processing and comms in one package.

    As an alternate perspective, for a flying vehicle I’d strongly advocate a big+little combination of processors. e.g. a Cortex-M3-ish to do the IMU, basic stabilization,failsafes and the R/c interface, with a generic (serial, USB) connection for a “high-level” controller. Makes a lot of sense in that case because you want a dedicated “closed-ish” box doing that “mission critical” processing … and you’re not going to want to touch that code very often.

    Also it lets the Open community use their processor board of choice. Your Beagle/Pi/Android sitting on top can be running slow, buggy, development code to your heart’s content.

    Does that model fit here? Or are the AUV dynamics slow enough that we’d trust, say, an Android “service” to handle the navigation and basic shipboard controls?

    All that said, I haven’t used the IOIO. If it makes it _that_ easy, it could well be worth it.

  8. Mike Godin says:

    Part of the rationale for suggesting the smartphone approach was automatic localization. I.e., if you use a smartphone that was sourced locally, then it should work locally. It also should speed up the Rev 1 design. Since the beaglebone can run Android, it could replace the smartphone in future revisions (perhaps when there is an EE willing to do cape design). Meanwhile, how about smartphone + IOIO boards?

    • Phil Marcelino says:

      So the AUV is going to be controlled via an Android App?

      • Mike Godin says:

        The AUV will not necessarily be controlled by an Android app… But doing so would allow a common code-base between rapidly developed vehicles controlled by a smartphone and more modular designs controlled by a beaglebone, for example.

  9. Aaron Marburg says:

    I’ve also been wondering if there’s a market need for a “smartphone without the display” for project like this, but I think you’d quickly lose the price advantages from mass production … and I doubt you’d ever make everyone happy — GPS or no GPS? no camera? good camera? great camera? good IMU or great IMU? etc…

    For cases where small package weight and volume matters (small things that fly) I’m afraid tightly integrated and bespoke is the best way. For the rest of us … a modular approach? I thought OpenROV’s use of the Beaglebone was a smart move, for example. Maybe there’s a case for an “autonomous robot” cape for the BB? Or perhaps such a thing already exists?

    We might benefit from modularity as well, as per Phil’s comment. Different cell modems for different regions worldwide (modulations and freq bands)? Or provide the option to replace the cell modem with a 900Mhz link, for example.

  10. Phil Marcelino says:

    This made be worth a little trade study. How much for the parts to replicate what a cell phone can do. If we have a EE who can design a board with all of those components, then it may make sense to fab out a board with all of the components.

    The other concern is what happens if the AUV goes out of cell coverage? I think we’re going to need a some RF communications on there as well.

Leave a Reply