Close

Does this project spark your interest?

Become a member to follow this project and don't miss any updates

SolarSurfer

A robotic solar-powered surfboard that will travel from LA to Hawaii! It's Arduino-powered, satellite connected, and collects ocean data.

7 56 45
Enjoy this project?
Share on twitter   Share on Facebook

This project was created on 06/29/2014 and last updated a day ago.

Description
The SolarSurfer is a robotic solar-powered surfboard that will autonomously travel from LA to Hawaii. We’ve been thinking about this project since September 2013 and started working on it in June 2014. It will be launched on its three month journey by August.

The SolarSurfer is built onto an 8 foot surfboard. A 120 W solar panel and lead acid battery power the electronics and the BlueRobotics thrusters. The surfer is guided by a 3D Robotics APM2.6 with a uBlox GPS. A RockBLOCK satellite radio from Rock Seven let’s us communicate back and forth with the SolarSurfer to monitor its position, status, and update its course. Temperature and pH sensors collect useful ocean data along the way.

The ocean is a harsh place - corrosive saltwater, intense sunlight, constant motion, and life everywhere. There's lots of challenges to overcome and a lot of potential for awesomeness.

Stay tuned.
Details

When we first started thinking about this project last year, we had no trouble finding the right microcontroller, sensors, GPS, even a SATCOM link, but we couldn’t find a good thruster. Everything we could find was very expensive or would corrode during the long trip. That launched us on a quest to design an affordable, high-performing thruster, which we did. You can check it out at the BlueRobotics website. The SolarSurfer will showcase the thruster’s performance and endurance.

The project is open-source and we'd love your input and contribution!

Please see the repositories on Github for a detailed description of the design and hardware.

Components
  • 1 × 8 Foot Surfboard Foam currently, upgrading later.
  • 2 × BlueRobotics Thruster-100 For propulsion and steering.
  • 1 × 3D Robotics APM2.6 The brains.
  • 1 × 3D Robotics uBlox GPS & Compass For position.
  • 1 × Rock Seven RockBLOCK Satellite Radio For communication.
  • 1 × 120 W SunPower Solar Panel For energy.
  • 1 × Morningstar Solar Charge Controller For power regulation.
  • 1 × 12V, 18Ah Sealed Lead Acid Battery Enough power to keep the electronics running all night and on a cloudy day.
  • 2 × Pelican Cases For protection.
  • 1 × Airmar WS-100WX Wind Sensor Wind, air temp, air pressure sensor

Project logs
  • Navigation Code Update

    a day ago • 0 comments

    In all of our previous tests, the navigation code has been dead simple: calculate the heading from the SolarSurfer to the next waypoint and point in that direction. This works great and should be sufficient to get us across the ocean but we wanted to upgrade to something a little better.

    We've modified the code to all the SolarSurfer to track the vector between the last waypoint and the next waypoint so that it stays on single line. If it drifts due to current, it will tend to go back to the line. This should result in better tracking and most importantly, a much prettier live map.

    We haven't tested it in the water yet, but here's some simulations so that you can see the difference. 

    First, here's the original behavior. The blue circle represents the last waypoint and the blue X represents the destination. The vector field shows the desired heading of the SolarSurfer based on where it is. As you can see, it always points straight for the destination, no matter where it is.

    Next, here's the new vector tracking behavior. It's still really simple: it just calculates the difference between the heading from the last waypoint and the heading from the current location and tries to make that zero. It's meant to be a fairly gentle correction. There's not need for tight tracking here.

    There's a few consequences of doing this purely with angles instead of distances. First, the tracking will be loose far away from the waypoint and tight when near to the waypoint. This seems like a reasonable consequence.

    We're going to test this in the next week or so.

    Stay tuned.

  • Satellite Comm

    9 days ago • 0 comments

    Since the trip to Hawaii is going to take many weeks, one of our requirements for the SolarSurfer is to have two-way satellite communication during the journey. We decided to use the RockBLOCK modem from Rock Seven to fulfill this requirement.

    The RockBLOCK features a modem which can talk with the Iridium satellite constellation. The Iridium satellite network is unique in that it can reach everywhere on Earth. This is important to us, because the SolarSurfer will be operating out in the open ocean - an area not serviced by many other satellite constellations who focus only on terrestrial applications.

    By using the IridiumSBD library for Arduino, we able to start sending messages over the air the day we got the modem. This library employs a callback function to enable processing during the possibly-long message sending process. To play nicely with the Iridium callback, we organized our control code into a function that could be called from the Iridium callback and from the normal Arduino loop function. This allows the SolarSurfer to operate normally whether sending an Iridium message or not. You can check out our implementation in the src/solarsurfer.pde file of our SolarSurferCore repository.

    On the ground side, the Rock Seven Core service allows users to configure message handlers. Specifically, you can email addresses, which are great for debugging, and HTTP services, which are great for actually building a service around your Iridium-powered device. We created a database-backed API called SolarSurferAPI to listen to the Rock Seven service. This allows us to record all of the messages that we receive from the SolarSurfer so that we can analyze them later. The SolarSurferAPI project listens to HTTP POST requests from RockSeven and stores the Iridium payloads in a MongoDB database. The API is written in JavaScript with NodeJS and is designed to run on Heroku.

    One of the limitations with the Iridium service is the extremely small amount of data that can be sent and received. Iridium messages can be up to 340 bytes, although Rock Seven charges for every 50 bytes. Since messages can be up to 20 cents each (if you prepay for only 50 messages) we opted to build our messages around a 50 byte limit. To put that in perspective, the size of this log post is about 3500 characters or 14,000 bytes. It would cost a whopping $41 to send this content over Iridium through Rock Seven's service. It's a good thing normal Internet access doesn't cost that much...

    With this data limitation, every single byte counts. In order to make passing information between the API and the surfboard as painless as possible, we created another repository called SolarSurferMessage solely to define message types and their content. This repository defines the message formats in a JSON text file and can automatically serialize and deserialize messages. Since SolarSurferMessage is also written in JavaScript, it is included directly in SolarSurferAPI. However, SolarSurferMessage also includes a script that generates an equivalent C++ message library for SolarSurferCore.

    With everything in place, the end-to-end communication looks a bit like this:

    We had this setup built in time to try out for our Ocean Test No. 3, and the setup worked great! We were even able to make auto-updating maps and graphs using data from SolarSurferAPI that we used to follow the surfboard while it was out in the ocean overnight - but more on that in a future post.

    Thanks for reading, and stay tuned for more SolarSurfer updates!

  • Ocean Test No. 3

    a month ago • 0 comments

    8/8/14-8/9/14 - This test is a big deal. Over the course of almost 24 hours, the SolarSurfer traveled approximately 20 km in the open ocean, miles off the coast of Los Angeles. 

    We were fortunate enough to have access to a boat for this test. We took the SolarSurfer out to about 2 miles off the coast on Friday morning. After some quick debugging, everything worked great and we followed it out to sea for a few hours. We turned our boat around and left it out in the ocean overnight.

    As the sun went down, the power tapered off appropriately and finally shut down around 6pm. The battery kept the electronics going so we had satellite messages through the night. The SolarSurfer drifted pretty far during the night and made a fish-shaped pattern. 

    The following day, it woke up in the morning and continued on its way without a hitch. We intercepted it in the middle of the day, picked it up, and brought it home. Total distance traveled was about 20 km.

    Successful test!

    There's an interactive map here:

    www.bluerobotics.com/images/maps/SolarSurfer-SMC-GPS.html

View all 6 project logs

Discussions

David Cook wrote a month ago null point

Great project! Two questions:

1. At full speed, how long would it take to go from Los Angeles to Hawaii?

2. Based on the night drift, it looks like you are fighting ocean currents. Would it be better to go from Hawaii to Los Angeles?

David

Are you sure? [yes] / [no]

Rusty Jehangir wrote a month ago null point

Hi David, thanks!

1. Average speed during sunlight hours will be about 2 knots. Assuming roughly 12 hours of sunlight, we'll go 24 miles a day and it will take 3-4 months. Since winter is coming it will likely end up being a little longer.

2. We did some research and found OSCAR, NOAA's database for ocean surface currents. If you look at the ocean between LA and Hawaii, the currents are usually pointing towards Hawaii (at about 0.1 m/s). The Santa Monica bay where we tested was much different and unpredictable.

Rusty

Are you sure? [yes] / [no]

Adam Fabio wrote 3 months ago null point

Great project Rusty! Thanks for submitting SolarSurfer to The Hackaday Prize! A trip from LA to Hawaii is a HUGE undertaking - and it looks like you're off to a great start! I'd love to see some video of those first R/C tests. Suggestion - if you have the resources, look into adding a salinity sensor (Conductivity). I spent some time working in the marine electronics shop back in college. From what i learned there, marine biologists would love that data!

Are you sure? [yes] / [no]

Rusty Jehangir wrote 3 months ago null point

Hey Thomas, glad you like it.

The surfboard has a weighted keel underneath. It's made of steel and has a weight at the bottom where the thrusters are mounted. The current board is a little too big and stable when upside down but we're moving to a smaller, thinner board.

In terms of collisions, we'll be able to update the course and waypoints at any time so that we can divert if necessary. I imagine that the sheer size of the ocean will make that unlikely.

- Rusty

Are you sure? [yes] / [no]

Thomas wrote 3 months ago null point

How is the legal situation for a project like that?
I have no idea :D

Are you sure? [yes] / [no]

Rusty Jehangir wrote 3 months ago null point

Hey Thomas, I'm no expert on the legal situation. There's some info related to autonomous boats here:

http://www.microtransat.org/faq.php

The MicroTransat Challenge is an autonomous transatlantic sailing competition. This question is particularly relevant:

"Q: Do the boats have to include any kind of autonomous collision-avoidance system to prevent collision with other floating objects?
A: No you don't have to. The International Rules for Prevention of Collisions at Sea (COLGREGs) define a vessel as carrying passengers or cargo, it is our understanding that this doesn't class an autonomous boat as a vessel and therefore exempts it from these rules. There is no current legal status for autonomous boats, from what we can tell in speaking to the IMO and both the UK and French coastguards it would be classed as a buoy not a vessel."

Are you sure? [yes] / [no]

Thomas wrote 3 months ago null point

Hi! Very nice project.
How you make sure it does not turn over?
I could see that you have some kind of arm for mounting the thrusters. Is it stiff?

How you want to avoid collision with ships or buoj? Tracking ships and update course if there could be a collision?

Looking forward to see how it goes!

Are you sure? [yes] / [no]