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:

SQ2013-06-11a: Port ROS, MOOS (or other robot operating system) to this architecture, or develop a lighter-weight custom software framework?

Resolved Questions:


4 comments on “Software
  1. Bob Allen says:

    Hope it’s not too late to offer Jon some moral support here: I have to agree on two fundamental points.
    1. If you’re serious about an Open Source project, then Linux makes more sense than anything else out there. Period.
    2. The Raspberry Pi is good choice for the same reason BeagleBone is; both are relatively low cost (remember: we’re talking amateur contributions to get the maximum participation more often than well funded research projects with dedicated staff) and both platforms have a wide base of users already.

    When evaluating where to spend time on an Open Source project, it’s important to pay attention to how active (and large) the community is (OpenAUV is really small so far). Making choices that _limit options_ going forward, and so early, will doom a project quicker than most anything else we could do.

    If people really felt attached to MOOS, then great; Open Source projects branch all the time. What I suspect is the _most_ important is defining a set of expectations (maybe _more_ that one set) that people jumping on board can rely on so they can contribute to a stable target, not shifting sands.

    So let’s say we put forward a straw-man platform configuration that at least seems like it can be viable and remain open, and give it a shot. Personally, I think Jon has outlined a lot of possibilities (perhaps, _too_ many) so a “Minimally Viable Platform” with plenty of directions for expansion seems like a good place to start. For example:

    – Raspberry Pi processor
    – which brings with it a USB hub _AND_ Ethernet (for the benefits already given)

    That would allow for a wide range of add-ons and even additional _layers_ of specification specific use cases.

  2. Jon Riley says:

    As a suggestion the Raspberry Pi may be a useful starting point.

    It is small enough to enclose in a pressure hull, low cost – in case of the occasional flooding 🙁 , operates efficiently from 5VDC and has a linux kernel that enables a plethora of software options that can be either downloaded free or developed and verified at low cost.

    The key information here is that the hardware is low cost (less than USD80), runs linux which means you (or your kids) can develop and test the software on any PC. It is also available globally.

    The Raspberry Pi supports a variety of interfaces to give the maximum creativity for adding kit to your sub, and it doesn’t use much power (depending on what external stuff you power via USB etc), but typically less than 1.2 amperes @ 5VDC.

    If you have a lot to lose if your sub fails, the it would also be possible to operate multiple Rasberry Pi’s in a fault-tolerant config (with heartbeat between them to decide the master) with multiple power sources to protect against faults.

    The I/O options including USB support (can be expanded with a USB hub if necc) give the opportunity to use cameras (multiple), audio (sonar, ultrasonic depth sounder) and there is PIO or USB-to-serial options for driving control systems.

    The main disk storage of the Raspberry Pi is SD (and potentially more via USB) so there are plenty of Gbytes of storage for telemetry data.

    Although there are no on-board sensors on the Pi (for pressure, temperature etc), there are a number of compatible transducers for that including digital gyroscopes and digital accelerometer modules, temperature modules (all low-cost miniature design) that are available with serial I/O (to suit USB to serial) or interface via PIO.

    The Raspberry Pi is also equipped with a LAN interface in addition to the USB interfaces. This could be ok for in the lab or if you get to tether (via UTP, coax or optic fibre), but may also be adapted externally for network options.

    The Raspberry Pi also works fine with many low-cost USB WLAN adapters (or mini WLAN routers with external antenna) too for when the sub is on the surface, since radio frequency signals do not propagate/travel very far underwater. Under programme control, there is no reason why the Pi could not shut off power to the WLAN router for example on submersion and restore power to the WLAN router on re-surfacing.

    The Pi supports audio out too. That could be used for acoustic communications (or chirps or pings). Since sound travels a lot farther underwater (and approx four times faster than in air), there is a world of sound for a microphone underwater and a whole lot to learn from echos (e.g. sonar, depth sounder etc) like underwater radar. I have used a Creative Labs USB (Sound blaster) thumb-size audio adapter with stereo mic. BTW there are are a lot of free audio recording and DSP applications available.

    There are plenty of low-cost stepper motor interfaces available too (to adapt from either serial or PIO) to a plethora of off-the-shelf steppers. (although not so many salt-water proof!) These could give important control of ballast shift (static pitch trim, roll trim), dive fins (dynamic pitch), buoyancy device (e.g. piston type or valves) and rudder controls. For the advanced builder those might be three axis robotic arm & grabber etc.

    Remote Command and Control for the Rasberry Pi is excellent via SSH or Telnet, but it also works as a web-server, sftp server etc over IP (presuming an IP network is available). It could be customised for more optimised protocols (over twisted pair, coax or optic fibre – if tethered).

    The elegance of the Raspberry Pi is that, as a fully functional linux computer it could readily be adapted to autonomous operation. This is important when communication is lost (e.g. following submersion if not tethered).

    Sub-surface, a pre-determined course could be navigated. This could be as simple as a set of vectors (heading, depth, distance) navigated by reading the set from a file and dropping to the input queue. In the absence of a course, or after some elapsed time it would be probably good to fail safe. That is, to trigger ‘blow ballast’ and return to surface to try to restore communications via WLAN or mobile network or satellite modem or VHF, UHF, HF, MF, LF etc.

    The Raspberry Pi could be interfaced to external systems via the PIO as noted earlier. However, there are off-the-shelf products like the labjack that could make it easier for those who need numerous independent I/O (digital and analogue) for the sensors aboard their sub and the switches (including solenoid valves etc for buoyancy controls, lighting, propulsion control, power switch-over to backup power – for when battery voltage indicates depletion, flood sensors in the bilge, shock/collision sensors… limited by imagination).

    The size of the Raspberry Pi makes it also ideal for a mini pressure hull.

    Naturally, there are plenty of miniature microprocessing options, (arduino, android etc) but by my reckoning, if you want your code to survive for a few years then developing under linux will enable that (since your efforts in software will survive multiple hardware generations).
    I started thinking about this stuff many years ago and I have tried many options with varying success. Due to the power limitations available in a sub, the Raspberry provides the easiest starting point for those hoping to make progress rapidly without major expense.

    I hope this helps.
    Cheers, Jon

  3. Cecil Johnson says:

    i think all platforms canbe used . the question is which i easier ???
    beaglebone would be latest i guess

  4. Phil Marcelino says:

    Given that we’re looking at making an autonomous vehicle, I think that starting with MOOS would be a better way to go.

Leave a Reply