Project Logs

Collapse

• Monterey Mission Simulation

  Josh Villbrandt • 10/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 Jehangir • 10/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 Jehangir • 09/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 Jehangir • 09/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 Villbrandt • 09/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 Villbrandt • 09/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 Jehangir • 09/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 Villbrandt • 09/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 Jehangir • 08/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 Jehangir • 08/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