BeagleBone and DS18B20 Temp Sensor

After deciding to switch over the the BeagleBone Black, we have been reconsidering using an Arduino to measure environmental variables. Using the numerous I/O pins on the BBB is not only easier, but more efficient in size and speed. We've also decided that we will not be purchasing pH, DO, and Salinity sensors for the prototype...they will be add-ons for those who want them.

Before starting, read this quick explanation on device tree overlays on the BeagleBone. After understanding the basics of pin-muxing.

Also refer to this post by HipsterCircuits (much of the following taken from the post). That post is the basis for the explanation below.

Then download the device tree overlay package (can't use apt-get as that package does not have the -@ compiler) use Robert C Nelson's source install:

After installing the software, make the file executable, and then run the bash file to install device-tree-overlay (dtc) from the source:

Then copy and paste the code found in this post to BB-W1-00A0.dts (by creating this file).

Compile the .dtbo file:

Copy the .dtbo file to /lib/firmware:

Mux the pins (this must be done on every reboot -- we added it to the init section of our script):

Attach the DS18B20 one-wire temperature sensor. Use a 4.7k resistor to attach the sensor (for more information read this post). Then attach the white wire to "P9_22", the black wire to "P9_46", and the red to "P9_3".

After muxing the pins and attaching the sensor you should see a new device appear in /sys/bus/w1/devices. Use this unique id (ours was 28-0000049acf0) to replace the ID in the code below.

Create a python file similar to the image below (download can be found here):

And this is the output on the BeagleBone:

As you can see, this is not entirely accurate, but a .5 accuracy will work fine for our project. The pressure is also calculated using 14.7 psi, which should atmospheric pressure at sea-level.

This surprisingly easy setup will be useful for our project. By embedding this sensor code as part of a python module in our project, we will be able to easily read the temperature both above and below the surface of the water.

BeagleBone: MJPG-Streamer + C920

One reason for testing the BeagleBone Black was because of its processing capabilities. After some research it seemed as if it would work well streaming video. We decided to try MJPG-Streamer (which we had previously tried here on the Raspberry Pi) with Logitech's C920 Webcam. We chose to use this camera because of its HD capability, onboard H264 video encoding, and USB compatibility. Below is the camera taken out of its case:

The dependencies need on the BeagleBone and for the C920 are slightly different. First update and upgrade your operating system to insure that everything is up-to-date:

Below is a list of the correct dependencies. All work with apt-get install (for example, to install g++ use sudo apt-get install g++):

• g++
• cmake
• build-essential
• imagemagick
• pkg-config
• libv4l
• libv4l-dev
• v4l-utils
• v4l2ucp
• libjpeg8-dev

Now with the dependencies installed you can download MJPG-Streamer from our forked repository:

Make a symbolic link to the videodev2.h file:

Finally, install MJPG-Streamer:

After setting everything up there still may be an error that says the V4L2 Device isn't loaded. This happens because the uvccamera module is not loaded. To load the module:

You might need to switch between loading and unloading the module to get MJPG-Streamer to work. To unload the uvcvideo module use this command:

To play the video use the MJPG-Streamer commands and view it from the webserver (https://<localhost>:8080)!:

 You should see a 1280x720 image with 30 fps! A clear, crisp, and speedy stream. Perfect for the submersible. After a long, long journey looking into the different streaming methods available, it seems that MJPG-Stream is the best option for our project.

RasPi Camera: MPlayer and Netcat

After using GStreamer while moving the base of the camera we found that the image became very distorted. Using this in our submersible therefore wouldn't be possible. We then looked into other streaming methods using the Pi camera.

Although the MPlayer and Netcat combination is the recommended streaming method for the Pi's h264 video it wasn't as fast as we had wanted at first and had terrible latency. This combination almost matched MJPG-Streamer in speed, but unfortunately did not do well with a lot of movements at once.

Software:

• Netcat (Windows) ---> Chrome might block this download. Try Internet Explorer.
• MPlayer (look in MPlayer and Netcat for Windows folder)

Both of the above programs are located on our download page precompiled. The Netcat download should already be compiled and we thought it would be nice to share the MPlayer software as it was difficult to compile. If you would like to compile from source you must first download MinGW and then use its GCC compiler (directions on doing this can be found here). If you would rather not, the MPlayer download can be found on our downloads page in the folder MPlayer and Netcat can be found using the link above.

After installing MPlayer and Netcat on your Windows machine, streaming the video is extremely easy.

Command on the Raspberry Pi (w/ RasPi Camera):

Command on the Windows machine within the directory containing both MPlayer and Netcat:

And it's that easy!

We have found that in order to decrease the video latency, stream from the pi at a specific bite-rate (-b) and at a smaller frame rate then MPlayer is reading the stream, but it does not even compare in speed to other streaming methods.

This streaming method is the expected streaming method for the Raspberry Pi camera. Although there are ways to speed up the stream (namely reading the video at 60 fps while streaming it at 30 fps) they are not realiable. At points it streams video with low-latency, but at others it lags unexpectedly. Our next video post will have our final video streaming decision....

Measuring Battery Life -- BeagleBone Black

As part of our float we want to be able to constantly check the battery life of our submersible. To do this we wanted to be able to use the BeagleBone. Because the ADC (Analog Digital Converter) on the BBB (BeagleBone Black) has a max voltage of 1.8v, we needed a way of dropping the 24v battery. To do this we used a voltage divider. By using the voltage divider to step-down the 24v to <1.8v we are able to accurately measure voltage by using a simple ratio. With this measured voltage we can make sure that our 24v LiFePO4 batteries never drop below 20v (the voltage is each cell should be 3.2v when fully charged and 2.5 when empty)


First, we needed to calculate the Vout using the voltage divider formula:

We needed a voltage <1.8v and therefore used a 47 ohm and a 1k ohm resistor to drop the 25.6v to approximately 1.15v.

Vout = 25.6(47/1047)
Vout = 1.15

By measuring the voltage across R2 (from Vout to Ground) you will see a voltage of around 1.15v

Next you need to use Ohm's Law and Joule's Law to calculate the power consumption of the resistors. Using V=IR and Wattage=I^2R you should find the power consumption of R1 to be a little over .5W (as a shortcut you can use this calculator).

Our setup uses 2W resistors and still gets a little hot, although this is expected while using resistors and high powered devices. Also make sure that R2 is less than 1K ohms as that will interfere with the analog readings.

To measure the voltage with the BeagleBone we used the ADC capabilities Adafruit's BBIO Library. By residing the voltage periodically and then comparing it to a pre-determined ratio we're able to accurately measure the battery life. An image of the code is below:

If you would like to download the code we used find it at our GitHub Page. 

LED Heat Sinks

For a couple of weeks we have been trying to figure out how to situate our LED lights so that they don't cause problems with drag or camera view. We have tried about a dozen different options and have switched back and forth between them a bunch of times.

The original idea was to put them in a ring around the submersible. This was quickly scrapped as it takes a lot of material, adds to surface area, and would be hard to machine.

LEDs in a Ring around Submersible

We then realized that it would be easier to create sections of the ring that each house an LED light and spread them around the submersible. This still had some of the same problems and meant that each light that broke would need an entirely new housing that would have to be custom created.

LED module for outside

We were advised to use pre-made heat sinks and just create a mounting bracket of sort for the LEDs. The LEDs would then go inside of the submersible between the camera's and rotate on the same rod. This looked like a great solution at the time and meant we could use fewer lights (as the same ones would look down and forward). Unfortunately we then made the decision to use 4" PVC for our submersible. After creating a CAD model we found it was almost impossible to fit this inside of a 4" pipe.

Triangle for 3 LEDs

Triangle heat sink (bigger holes for the lens)

We then went back to external modules, but made them so that the LEDs could be replaced without having to replace the entire module. Again we were advised against this and tried to fit the LEDs into the inside.

We came up with a couple different ways to do it: putting and LED strip across the top or bottom or, alternatively, putting them vertically. While changing to this design we also made some changes to our camera layout. We decided to have both a webcam for video streaming and two pi cameras for stereoscopic vision, and this makes the dome much more crowded and so harder to work with.

Strip across the bottom

Vertical LEDs  strip between cameras

Float V2: Spooling Half

We have just recently finished creating the half of the second version of our float. After looking at the finished first float, thinking about its function, and contemplating its size, we realized that it was overkill. We came up with a solution which is sleek and more effective.

Float V2 is made out of of two pontoons connected together using PVC bracing. One side contains the spool and the spooling motors (the spool happened to fit inside the pontoons perfectly) while the other contains our batteries, wireless communication device, and other electronics. An image of the spool in the pontoon is below:

We first made the bracing to hold the two floats together. We did this using some inch-and-a-half PVC pipe that we had lying around from the previous version.

To attached the large spooling motor we then found that, using the same Plexiglas mounting plate we had used last time, we could easily line up the pulley on the motor to the pulley on the spool. We held the motor to the top using a u-bolt which also allows us to tighten/loosen the driving belt (refer to the image above).

To attach the motor used to organize the tether, we drilled four holes in the top of the pontoon and attached the motor using 4 bolts and the motor's mounting face. We then needed to create another gear at the opposite end of this motor to attach the belts used to organize the tether (for more specifics on this idea check out our previous blog post). We realized that this motor's shaft lined up perfectly with the u-bolt used to attached the motor on the other side of the pontoon. We then created a piece of Plexiglas which could be put on the u-bolt and would have a ball-bearing that holds the second pulley in our system. An image of this motor is below:

By nature u-bolts can be raised and lowered. This allows for tensioning of the spool's driving belt. By adding slots on the pontoon for the u-bolt we were also able to easily tension the organizational belt.

Below is the finished V2: Part 1 of out float (and Nick)!