Close
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 »

  • 2 × Pelican Cases (1200) For protection.
  • 1 × Airmar WS-100WX Wind Sensor Wind, air temp, air pressure sensor
  • 1 × Atlas Scientific pH Sensor For measuring pH and ocean acidity
  • 1 × Custom made steel keel For thruster mounting. A weight on the end allows the surfer to right itself if capsized
  • 1 × BLDC Motor Monitor Board (Custom) Measure thruster rpm, current, voltage to diagnose jams, short circuits, etc.

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

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates