Close

Does this project spark your interest?

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

0%
0%

SolarSurfer

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

Similar projects worth following
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 later this year.

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!

Inspiration:

The SolarSurfer project started because we were looking for something cool to do. Being surfers and engineers, the project was a perfect fit. 

When we first started, 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.

Open-source-ness:

The project is open-source and we'd love your input and contribution! The software is available on our Github page and licensed under the GPL license. We leverage a lot of inspiration from other open source projects like ArduPlane and ArduCopter.

Wherever possible, we used open-source hardware. The primary computer is an APM2.6 autopilot from 3D Robotics, which is open source. There are two custom circuit boards on the surfer: a BLDC motor monitor that we custom designed to measure thruster RPM, current, and voltage, and a Power Monitor that measures power from solar panel to battery, battery to load. Both boards are open-source and also available on Github.

The mechanical design of the SolarSurfer is also open-source. The design is documented through the drawings, photos, and component lists on this page.

The thrusters, although not open-source, are well-documented and CAD models are available for anyone who is interested. Check them out on BlueRobotics' website.

Connectedness:

The SolarSurfer is a connected device. Even though it will be out in the open ocean for months at a time, it keeps constant contact with the internet. A RockBlock Iridium satellite radio sends messages every 5-30 minutes. The messages are received by our web server and stored in a database. We've built an awesome web app to visualize the SolarSurfer's trip in real-time.

The online interface is built around the SolarSurferAPI, which stores raw data and makes it available to anyone in JSON format. The API is well documented on our Github page if you want to check it out!

The SolarSurfer's connection to the internet is absolutely critical to its functionality. The SolarSurfer has a number of sensors that are constantly collecting data and sending it back to shore. With multiple SolarSurfers, a lot of interesting data could be collected and accessed via the web. It could be used for weather predictions, oceanographic data, etc.

In addition to send data back to shore, we have the ability to send messages to the SolarSurfer while it is in the middle of the ocean. That means we can update its waypoint path and change other settings remotely!

The online interface (which will be public in the near future) shows a live map view of the current trip. There are also tabs with data plots, raw data, commanding (which is not publicly accessible), and simulations. We plan to expand on the interface to show more data in the cleanest format possible.

Why is it cool?

Glad you asked. We think this is a really cool project for a whole bunch of reasons:

  • Ocean crossing, data gathering, autonomous robot!? That's awesome.
  • Multidisciplinary. Like any robot project, this one required mechanical, electrical, and software skills to build.
  • It has the potential to do incredible things in the future:
    • Collect ocean data that is not measurable with satellites like pH, subsurface temperatures, currents at depth, wave height, wave period, air temperature, air pressure, etc.
    • Collect biological data such as marine mammal sounds, population movements, etc.
    • Collect ocean data at a massive scale with many vessels deployed simultaneously

It could do all this at a fraction of the cost of manned vessels.

Innovation:

We're not the first to do this by any means. People have been sending autonomous vehicles into the ocean for years. Several have made it all the way across the ocean. We think the innovation...

Read more »

  • 1 × 8 Foot Surfboard Foam currently, upgrading later.
  • 2 × BlueRobotics T100 Thrusters For propulsion and steering.
  • 2 × BlueRobotics Basic ESCs For thruster control
  • 1 × 3D Robotics APM2.6 The brains.
  • 1 × 3D Robotics uBlox GPS & Compass For position.
  • 1 × 3D Robotics Power Module For current and voltage sensing.
  • 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.

View all 18 components

  • Monterey Mission Simulation

    Josh Villbrandt10/11/2014 at 06:33 0 comments

    We've created a mission simulator to better estimate SolarSurfer performance on the way to Monterey. We are using data from our last test in Marina del Rey to inform the simulation. The SolarSurfer's peak performance thus far has been 0.8 m/s with the solar panel providing 76W. Our avionics consume 4W, so 36W was going to each thruster at that point. The simulation also accounts for a 0.05 m/s ocean current going in a Southwest direction.

    With all of these assumptions, our simulator says that the SolarSurfer will take 30 days to get to Monterey Bay. We feel that this is probably pretty accurate and we will be update the simulation as we get better performance data during the first few days of the trip. Check out the simulation path (in red) compared to our intended path (in black.) The graph below also shows the thruster power consumption, absolute velocity, and total distance traveled for the first five days.

    In addition to this nominal scenario, we performed sensitivity analysis on a few key variables. Below are graphs showing the number of days required to reach Monterey Bay with varying thruster power settings and with varying the assumed ocean current velocity. On the thruster power graph, it is worth noting that while the thrusters are capable of utilizing 280W together, our current solar panel has only been providing 76W at our current location at this time of year.

    As always, our code is available on github. We are excited to launch and even more excited to share the adventure with you. We'll be releasing our public page with live data tracking Tuesday morning a few hours before we launch the SolarSurfer. As always, stay tuned.

  • Ocean Currents to Monterey

    Rusty Jehangir10/10/2014 at 00:32 0 comments

    In preparation for the SolarSurfer's trip from LA to Monterey (on October 14th), we've been looking into the expected surface currents along the way. This is particularly important since the SolarSurfer drifts at night and is at the will of the current. Fortunately, according to NOAA's OSCAR database, the currents will be minimal. The are mostly offshore at a speed of about 0.05 m/s, which is much slower than the SolarSurfer travels under power.

    Here's a plot of the region between LA and Monterey:

    And here's a zoomed out plot showing the entire west coast.

    Stay tuned for the launch!

  • Plans for Ocean Test #4: LA to Monterey

    Rusty Jehangir09/29/2014 at 06:43 1 comment

    Our next test is going to be a big one: we're going to send the SolarSurfer from Los Angeles to Monterey, CA. The total distance will be around 300 miles and will take 2-3 weeks to complete. We'll detail the whole thing here from launch to recovery, and we want to share our plans right now.

    We'll launch in early October from the Los Angeles area (most likely Malibu) around October 14th. The SolarSurfer will travel south of the Channel Islands and then out to sea approximately 80-100 miles from shore to minimize the risk of getting near other boat traffic.

    The SolarSurfer will then travel parallel to the coast before heading back towards the coast. It will return to shore in Monterey, where we will meet it. If successful, it will fully demonstrate the capabilities of the idea, the platform, and the interface. The whole trip should take about 2-3 weeks and hopefully we'll be able to retrieve it before the final Hackaday judging!

    Here's the proposed path:

    Stay tuned for more details about the launch!

  • Long-Term Design

    Rusty Jehangir09/29/2014 at 03:39 0 comments

    Our current SolarSurfer is just a prototype. It's completely functional but it's not pretty and it's not optimized.

    Wonder what the SolarSurfer might look like eventually?

    We've put together a concept design for our future SolarSurfer and we think it looks awesome. It's got a custom designed hull and all of the components are cleanly integrated. There's also a few key changes that we'd like to make:

    • Longer, v-hull design for low drag and added solar panel area
    • Swept keel designed to minimize seaweed entanglement and reduce drag
    • Three thrusters provide steering control even if one thruster fails or jams

    Here's some images of what that might look like.

    In addition to the mechanical design changes, there's some things we'd like to do to improve the hardware and software.

    • Isolate guidance and control computer (APM) from non-essential sensors like the pH sensor
    • Provide an serial API so that anyone can add a new sensor and add it to the satellite telemetry data easily

    If you have any suggestions for improvement, let us know in the comments!

  • SolarSurfer Electrical Schematic

    Josh Villbrandt09/28/2014 at 19:08 0 comments

    Hey all,

    We updated our central SolarSurfer repository with a diagram of the electrical schematic that the SolarSurfer is currently using.

    By the way, can anyone recommend a better program to create wiring diagrams? We used a simple drawing program (draw.io/) for this as opposed to a purpose-built electrical wiring application. Most of the wiring diagrams using the APM on the net don't look much more sophisticated. Let us know if you have some ideas. Thanks!

  • Real-time Tracking

    Josh Villbrandt09/26/2014 at 01:35 0 comments

    In one of our previous posts, we described the back-end architecture that shuffles data to and from the SolarSurfer over the Iridium satellite network. With a database full of vehicle telemetry in place, we now have the ability to build an application with real-time tracking of the SolarSurfer. By the time we launch for the Hawaii trip, we intend to share this application with the public, but for now we've been keeping its address private. The code, however, is publicly available under the SolarSurferCommander repo on GitHub.

    Our goal is to allow the widest audience possible to track the SolarSurfer, so we decided to build the app as a web app. The app is written in Javascript and built on the AngularJS framework - the latest craze in application design. Angular is a framework for "single-page apps" which means that the entire web app is downloaded and executed in the client's browser on the first request. Once loaded in the browser, the app is smart enough to update itself with the latest vehicle telemetry directly from the SolarSurferAPI and can display those updates without having to reload the entire page. This is more efficient than the classical web model which entails reloading the entire page (and not just the latest data) with each data request.

    In order to best track the SolarSurfer, the SolarSurferCommander app uses three different widgets to display telemetry. This first a map with a plot of the SolarSurfer location over time (pictured below.) This map also grabs the user's current location in location-enabled browsers and plots that alongside the SolarSurfer. This is helpful for us during Ocean Test No. 3 as we were able to track down the SolarSurfer using the relative location between the two points on the map.

    The second widget is a traditional graph / chart widget (we used HighCharts) that allows us to view various parameters over time. We currently have three graphs on the app - a power graph, a navigation graph, and a command and telemetry statistics graph. The power graph (shown below) helps us visualize the thruster power control algorithm with respect the current available sun energy and battery state of charge.

    As you can see from the graph, the thrusters are commanded to use less power (shown in blue) as the sun is going down. When the sun finally goes down (thrusters shut off and the blue line becomes flat) the battery slowly starts to drain (shown by measuring the bus voltage in black.) At the beginning of the next day, the sun starts to rise and the battery begins to charge. Once the battery is fully re-charged, the thrusters are allowed to use the excess power shown by the blue line starting to increase again. That's pretty cool if you ask me!

    The third widget that we currently employ is a simple text-based output of the latest telemetry message in JSON form. One of the benefits of the SolarSurferMessage package is that it automatically deserializes the raw byte-streams that we send over Iridium, so the telemetry messages from the API are actually in a pretty readable format. Even bitmaps and enums are automatically expanded to human-readable values.

    As mentioned, the live version of this tracking app is private at this time. (Although nothing is stopping you from cloning the you could clone the project from github and run it locally) We will soon be refactoring the app as SolarSurferInfographic and we promise to share it with everyone as soon as we do!

  • Navigation Code Update

    Rusty Jehangir09/22/2014 at 20:24 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

    Josh Villbrandt09/15/2014 at 00:21 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 and not just terrestrial locations like many other satellite constellations. This is important to us, because the SolarSurfer will be operating out in the open ocean.

    By using the IridiumSBD library for Arduino, we were 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 the full implementation in the src/solarsurfer.pde file of our SolarSurferCore repository.

    On the ground side, the Rock Seven Core service allows users like us to configure message handlers. Specifically, you can add 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

    Rusty Jehangir08/21/2014 at 06:43 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

  • Power Control Testing

    Rusty Jehangir08/21/2014 at 06:38 0 comments

    8/3/14 - Today we tested our power control scheme successfully. To maximize the distance traveled everyday, we must use as much power as is available from the solar panel. At the same time, we have to keep our battery topped off so that it will last through the night.

    We did this by implementing a PID controller that increases or decreases the amount of power sent to the thrusters based on the voltage across the battery. The controller tries to maintain 13.2V across the battery, which keeps the battery topped off without allowing it to draw too much current.

    We tested the system outside with the thrusters submerged in water but under very control conditions. A cutoff was established so that the thrusters would shutoff once there was too little power available.

    Works great!

View all 12 project logs

Enjoy this project?

Share      

Discussions

Funvill wrote 12/29/2015 at 10:17 point

Hello, its been a while since the last update. I was wondering how far you got with this project? 

  Are you sure? yes | no

Sean Hodgins wrote 04/10/2015 at 02:12 point

This is very similar to an Idea I had but have not acted upon yet. I like the use of the surfboard. I can't wait to see how it performs, when is the expected launch? My only concern is the durability of the board itself. Holding together in the unpredictability of the ocean could prove difficult. I see you said that there will be new versions, they look much more robust. 

  Are you sure? yes | no

steve morris wrote 02/08/2015 at 03:50 point

I enjoyed watching Rutgers Scarlet Knight RU27 underwater glider's 8 month crossing of the Atlantic in 2009, including the daily Twitter feed. I'm looking forward to tracking your mission. Good luck.

  Are you sure? yes | no

lami4ka wrote 09/28/2014 at 21:18 point
Also do you think its possible to put an underwater camera? It would be sweet to record any wildlife it may encounter!

  Are you sure? yes | no

Rusty Jehangir wrote 09/28/2014 at 21:26 point
We would love to do this but there's a few challenges:
- First, keeping a lens clean underwater for months would be difficult. I think it would get covered in algae.
- Second, if you want to send the pictures back through the satellite link, it takes a lot of bandwidth and would be expensive. They could be stored on an SD card and viewed later though!

Hopefully we can add a camera underwater in the future.

  Are you sure? yes | no

Dex drako wrote 01/07/2015 at 06:57 point

you could do what nasa has done in the past use a sliding lens cover.

say you use a 2 by 1 inch piece of Plexiglas as a window set in a track where only half of it was exposed to the water. at a set time a motor would kick in sliding the plate to the fresh side while also run the other side across a

squeegee cleaning it off for the next time.

  Are you sure? yes | no

benjamin wrote 05/02/2015 at 05:58 point

i am not exactly sure how to apply it or if it works reliably, but in theory a very thin layer of silver should prevent any algae from growing. i imagine letting a very thin spread solution of colloidal silver evaporate would leave you with a very fine silver powder. this could be mixed into a resin, applied to the glass and sanded and polished to excavate the silverparticles. just a thought. anyway - loving this project!

  Are you sure? yes | no

lami4ka wrote 09/28/2014 at 21:16 point
This is a sweet idea! One question - what happens if the waves flip it over?

  Are you sure? yes | no

Rusty Jehangir wrote 09/28/2014 at 21:24 point
Hey Iami4ka - There's a keel on the bottom with the thrusters and a big weight that's about 8 lb. If it flips over, that weight sticks straight up in the air and pulls the board back upright.

  Are you sure? yes | no

David Cook wrote 08/26/2014 at 02:50 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 08/26/2014 at 05:52 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 07/09/2014 at 05:20 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 06/30/2014 at 20:32 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 06/30/2014 at 20:52 point
How is the legal situation for a project like that?
I have no idea :D

  Are you sure? yes | no

Rusty Jehangir wrote 07/01/2014 at 16:03 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 06/30/2014 at 12:37 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

Similar Projects