The Motor Controllers

by Web FishMar 16, 2013 @ 12:34pm

Controls the direction and power of the propulsion pods. Translates the central processor decision making and the battery power into mechanical movement.

  • Current selection: Pololu Simple Motor Controller 18v7
  • Status: Undecided (under testing)

  • Criteria: Max current handling, standard I/O, small physical footprint, thermal footprint, cost 
  • Finalists: Pololu RoboClaw 2x5A Motor Controller, Arduino Motor Shield R3, SeeedStudio Grove Motor Driver 
  • Main decision factors: High sustained / peak currents, cost, standard serial bus interface

 (click image for larger view) 

Spec highlights:

  • Simple bidirectional control of one DC brush motor.
  • 5.5 V to 30 V operating supply range.
  • 7 A maximum continuous current output without a heat sink
  • Four communication or control options:
    • USB interface for direct connection to a PC.
    • Logic-level (TTL) serial interface for direct connection to microcontrollers or other embedded controllers.
    • Hobby radio control (RC) pulse width interface for direct connection to an RC receiver or RC servo controller.
    • 0–3.3 V analog voltage interface for direct connection to potentiometers and analog joysticks.



  • Still unclear if we will use UART or PWM to control the boards. We are using 2 pins either way;
  • If using UART, both boards will be chained;
  • Unclear if hat signature will be an issue until we mount in the navionics bay with the rest of the electronics modules;


Fun and Games with Adafruit GPS

by Web FishJan 24, 2013 @ 06:35pm

With most of the navionics building blocks arriving in the mail over the last 15 days and with our test mule build taking longer than originally projected, it's time to start tackling the core navigation functionality.

The final navionics bay design, layout and external connectors are still very much work in progress. For now we'll stick with experimental wiring in order to get all modules talking to each other and iron out all the conflicts. By the time we are done, the deck layout should hopefully be finalized.

Starting with the Adafruit GPS module on UART 2:

Initial plan was to use a one-way communication with the GPS module (read-only) to save one GPIO port for other use (GPIO 4 is normally dedicated to UART 2 / TX). After playing with it for a while, it became evident that the default update frequency of the GPS board (NMEA_UPDATERATE) is ~10Hz, flooding the serial port with data that is (kind of) useless for us (the distance we'll travel at maximum speed in 100ms is significantly less than the GPS margin of error :). So we'll need a two-way communication after all (for the PMTK_SET_NMEA_UPDATERATE command and a few other configs upon GPS initialization).

Another thing to point out about the MTK3339 chipset in the Adafruit GPS module is that it takes FOREVER to update the internal almanac data after cold restart. If you try to do this inside a building, it can spend a whole night without building a usable almanac table and getting a stable satellite lock. Fortunately, Adafruit provides an optional battery back-up (requires a simple battery holder installation and a 3V lithium battery). Once the battery is installed, the satellite lock time is DRASTICALLY reduced (by orders of magnitude) and the receiver is operational on the ground floor of a two-story building.

With all this behind us, the first module is on-line and operational:

Time for the first real-life test. I'll go into more details about the code in the Software section of the blog, but here is a summary of the test setup:

  • The GPS class provides real-time (1 second interval) updates of current longitude/latitude/altitude, satellite fix mode (None/GPS/Differential GPS), number of available satellites in the constellation and the current time offset in GMT (hh:mm:ss);
  • The main routine polls the GPS class every 3 seconds;
  • If there is a satellite lock, the data logger dumps the current location data in human-readable format in a text file on the on-board SD card;

So I dropped the board on the passenger seat of the car and headed to the harbor. Dana Point harbor is not the most signal-friendly place (tall cliffs, rich vegetation, etc). To add to the test, the GPS sensor antenna was pointed down (towards the car seat). A four minute drive from the top of the cliff to the tip of the island yielded this. Not too bad... 

A quick parse and paste into gives us a near-perfect data point distribution. Try guessing where the stop signs are on the test course:

View GPS Test - 1/24/2012 in a full screen map


By the looks of it, we might be able to get away without an external active GPS antenna. 

Next on the list: compass module.

The GPS Receiver

by Web FishJan 4, 2013 @ 10:47am

Provides current position (and optionally direction/speed). 

  • Current selection: Adafruit Ultimate GPS Breakout board
  • Status: Finalized

  • Criteria: Reliable satellite signal acquisition when installed inboard, standard I/O, small physical footprint, cost 
  • Finalists: Adafruit Ultimate GPS v.3, Sparkfun GPS LS20031
  • Main decision factors: External antenna connector (makes board mounting position and packaging less relevant), standard I/O on two GPIO pins, sensitivity

 (click image for larger view) 

Spec highlights:

  • -165 dBm sensitivity, 10 Hz updates, 66 channels
  • 5V friendly design and only 20mA current draw
  • PPS output on fix
  • Internal patch antenna + u.FL connector for external active antenna



  • Will not know for certain if external antenna is needed until the navionics bay design and mounting is finalized
  • As an added bonus module provides current time-stamp for syncing Netduino internal clock after reboot (no battery back-up for the clock on the Netduino board - anyone remembering early Apple II days?)


The Comm Uplink

by Web FishJan 1, 2013 @ 02:01pm

The only link between PilotFish and the rest of the (civilized) world. Provides a one-way channel for reporting position, status and other select telemetry.  

  • Current selection: Iridium 9602-I & SBD service
  • Status: Finalized

  • Criteria: Reliable coverage across the passage area, overall cost, standard I/O, manage-able power footprint, easy programmability/debugging, small physical footprint 
  • Finalists: Iridium 9602, Iridium 9603, SPOT Satellite Personal Tracker
  • Main decision factors: Universal coverage, cost (compared with the other Iridium terminals)

 (click image for larger view) 

Spec summary:

  • Frequency Range 1616 MHz to 1626.5 MHz
  • Multiplexing Method TDMA/FDMA
  • Idle current (peak) 195mA
  • Transmit Current (peak) 1.5A
  • Receive Current (peak) 195mA
  • SBD message transfer – average current 190mA
  • SBD message transfer – average power 1.0W



  • Iridium service cost is magnitudes higher than all systems based on the Low Earth Orbit satellite constellation. Unfortunately, LEO solutions do not have sufficient coverage over the North Pacific. On the flip-side, using a full-featured data modem allows us to customize the contents of the data message and provide additional telemetry to mission control;
  • Power draw upon transmission can be in the 2A+ - need to ensure navionics power pack can provide sufficient surge power (with or without solar boost)
  • Still need to determine the right antenna and antenna positioning


The Central Processor

by Web FishJan 1, 2013 @ 12:31pm

The heart of PilotFish navionics package. The board runs all decision-making software, reading input data from all sensors (navigation and others), controlling propulsion and directional control, feeding up-link telemetry data and ensuring data persistence for post-mission download. 

  • Current selection: Netduino Plus 2
  • Status: Finalized

  • Criteria: Low power footprint, as many I/O channels as possible, standard I/O, available off-the-shelf add-ons, standard storage, easy programmability/debugging, small physical footprint 
  • Finalists: Netduino Plus 2, Arduino Mega 2560
  • Main decision factors: 22 I/O pins with dynamic GPIO/Analog/UART/I2C allocation, Arduino shield compatible, sufficient code storage area, .NET Micro Framework, on-board SD card support

 (click image for larger view) 

Spec summary:

  • STMicro 32-bit microcontroller
  • Speed: 168MHz, Cortex-M4
  • Code Storage: 384 KB
  • RAM: 100+ KB
  • 22 GPIO pins
  • Up to 4 UARTS
  • I2C channel
  • micro sd (up to 2 GB)
  • input: 7.5 - 9.0 VDC or USB powered
  • output: 5 VDC and 3.3 VDC regulated


  • Even though 22 I/O pins look like a lot, in reality we'll need every pin available to communicate with the peripheral devices. Whenever possible, we might need to utilize I2C bus to preserve general I/O pins for "dumber" sensors and devices.