Tuesday 5 November 2013

Ship Computer Requirements, Software Versions and functionality

OK, on my previous post I tried to sum up the situation.
Here, I will describe my needs, what I want from a ship computer.
In the next couple of posts I will describe the design, and possibly some draft of the implementation.

So, what I need.

to start with, I need to have indication of apparent wind angle. Now, one might thing that this is rather entry-level requirement, why do I have to create a custom device in order to have this indication? simply because I have a rotating mast!

the next obvious requirement is to have apparent wind speed (Kn).
This should be straightforward, at least when the wind cups rotor works!.

Then I want to have magnetic heading and course (GPS) heading, along with Speed Over Ground.

Having this measurements, it is easy to calculate True Wind Speed, True Wind Angle and leeway.

More functionality and measurements will be added in subsequent development cycles.

To sum it up, the basic info I want to have, are as follows:

1. Apparent Wind Speed
2. Apparent Wind Angle
3. True Wind Speed
4. True Wind Angle
5. Speed over ground
6. Heading
7. Course over Ground
8. Leeway angle (=heading-CoG)

I want to have realtime update for these as well as logs.

This is for version 1 of the software.
For version 2, I will provide mechanism for uploading route and waypoints so that I can have VMG and ETA calculated in real time.

The ship computer will be headless.
It will be equipped with 2 Interfaces, a WiFi setup as Access Point, and a Bluetooth.
A third interface could be added, that of a GSM/GPR/3G usb modem, in which case the Ship Computer when within 3G/GSM range, could provide Internet Access for all onboard and the same time push on a land-locked server, info on it's whereabouts and environment, providing means of fleet management (this functionality will come on Version 3 of the software).

In all software versions, the UI will be divided in Primary UI and Secondary UI.
 
The PRIMARY User Interface will run on a tablet (an iPad on version 1, might use android for subsequent versions).
Through the Primary User Interface, the Ship Computer will:
In Software Version 1 report to the user all values, either collected or calculated. Early version of the V1 UI could be made up as a web page created by a apache server running on the ship computer, but eventually, Version 1 UI should be a native tablet application with lifelike instruments, animated needles, etc. Version 1 UI shouldn't need two way communication, the information flow should be only from the Ship Computer (the server) to the Version 1 UI (the client).

Software Version 2 UI will be a native application built on Version 1 but will additionally provide:
  • MapView, that will enable route creation.
  • Ability to upload route(s) to Ship Computer
  • Ability to activate specific route
  • Ability to show on map current position along with heading
Needless to say, the virtual instruments should be visible or readily available.

In Software Version 3, the UI should be almost identical to V2, the main difference being on the software running on the ship computer itself that should be able to send regular notifications with location and other critical information (heading, speed, sea condition (see the 3D accelerometer, later in the descriptions) etc. Also V3 of the software would need server-side software for collecting these info and for presenting them to users (users could be from your mom that wants to know you are sailing safe, to the yacht charter administration office that needs to know your whereabouts in order to better assist if required)

I have started talking on the Primary UI and ended up on the V3 Server-Side software!

So let's go back to the UI!
As said before, there's going to be a SECONDARY UI too.
This will be a one way (ship computer to device) communication, that will provide quick notification on major metrics, eg Speed Over Ground (SoG), Course Heading, Wind, etc.
On VERSION 2 of Secondary UI there's also going to be VMG, Distance to next Waypoint, ETA to Next Waypoint, ETA to Finish. etc.

I have decided to implement the SECONDARY UI on a PEBBLE watch:
The Pebble smartwatch is a fully programmable device (the SDK is freely available for download) and in contrast to most of the other SmartWatches or GPS Watches, it doesn't try to do all by itself, it doesn't even have a GPS!.
Instead, being programmable, it can communicate with a master device (server, smartphone etc) and get functionality through the other device's mechanisms.
It is slim, light, with a great paperwhite display, it's a breath of fresh air! (check out reviews on the net, eg  this one).

For the secondary UI to work, the Pebble should be paired over bluetooth with the Ship Computer.
The secondary UI will word independantly of the Primary UI, that is, the tablet can be turned off, run out of battery, fall in the sea or whatever, the Secondary UI will still work.
(just for the record, my initial design was with the Pebbled paired on the tablet, that might have been easier to implement but the Secondary UI would be tied up to the Primary. Instead of doing so, I added a bluetooth dongle on the Raspberry PI and set up communication between Raspberry and Pebble using libpebble, a library for OSX and linux, which I installed on Raspberry.)
Anyway, enough said, will provide all info on the solution presentation on a later post.

No comments:

Post a Comment