Posted by & filed under Coding.

Having had the need to have some sobjects clonable, I didn’t like that ICloneable was returning an object and I had to check for null before I call to Clone().

 

A better IClonable to the rescue!

 

Hope that helps!
Have fun coding!

Tags:

Posted by & filed under Coding, OpenROV.

While working on an disk image for the OpenROV, I needed to get NodeJS cross compiled on a Ubuntu x65 Box for the ARM based BeagleBone PC.

Right now (or at least the last time I checked), there was node NodeJS Ubuntu package for the ARM platform around, therefore we have to compile it ourselves.

Prepare the system

If you running a normal Ubuntu Linux 12.04 and want to compile for the BeagleBone, you will need a cross compiler like the packages gcc-4.6-arm-linux-gnueabihf and g++-4.6-arm-linux-gnueabihf

Just go and do

sudo apt-get install gcc-4.6-arm-linux-gnueabihf g++-4.6-arm-linux-gnueabihf

That about it for the preparation, pretty easy.

 

Compile NodeJS

Right now, I use NodeJS v0.8.11 from github. You can clone the repo and checkout the right tag. I don’t advice to use the master as this is a -pre version and I had issues with some modules using those.

git clone https://github.com/joyent/node.git node

cd node

git checkout v0.8.11

The thing is, the version 0.8.11 doesn’t just work if you try to cross compile it. you need to do a few changes.

Just open the file deps/v8/build/common.gypib with an editor and ad the line following line after ”variables’: {”

‘arm_neon%’: ’1′,

This will fix the issue you would have otherwise.

Now we can tell our system to use the cross compiler executables to compile:

export AR=arm-linux-gnueabihf-ar
export CC=arm-linux-gnueabihf-gcc-4.6
export CXX=arm-linux-gnueabihf-g++-4.6
export LINK=arm-linux-gnueabihf-g++-4.6

This will set the archiver (AR), C compiler (CC), C++ compiler (CXX) and the linker (LINK) to the correct executabels.

The next step is the configure step where we prepare the actual compilation.

./configure –without-snapshot –dest-cpu=arm –dest-os=linux –with-arm-float-abi=hard –prefix=/opt/node/

This will setup the the NodeJS source to be compiled for an ARM cpu with hard floating point numerics and the installation directory should be /opt/node.

This shouldn’t take too long and we can initiate the compilation:

GYP_DEFINES=”armv7=0″ CXXFLAGS=’-mfpu=vfp -mfloat-abi=hard -DUSE_EABI_HARDFLOAT’ CCFLAGS=’-mfpu=vfp -mfloat-abi=hard -DUSE_EABI_HARDFLOAT’ make –jobs=8

We need to set a few additional environment variables specific for the make command, but that will go and compile node for you.

This takes some time, I’ll wait ……. done? ok :)

Now you can install it on your system. We need to do this step so we can package it up for our destination computer. Just make sure there is not yet a directory called /opt/node!

sudo GYP_DEFINES=”armv7=0″ CXXFLAGS=’-mfpu=vfp -mfloat-abi=hard -DUSE_EABI_HARDFLOAT’ CCFLAGS=’-mfpu=vfp -mfloat-abi=hard -DUSE_EABI_HARDFLOAT’ make install

Now you can zip the directory /opt/node up and put it on your BeagleBone! Yeah!

 

Cross Compile node modules

Some node modules need native compilation to work or work faster. One of them being serialport.

Again, you need to setup some environment variables to use the cross compilers:

export AR=arm-linux-gnueabihf-ar
export CC=arm-linux-gnueabihf-gcc-4.6
export CXX=arm-linux-gnueabihf-g++-4.6
export LINK=arm-linux-gnueabihf-g++-4.6

And, you need some specific ones for node modules:

export npm_config_arch=arm
export npm_config_nodedir=/<path to the node source>/

The path in the second one needs to be the path of the actual nodejs sourcecode you used above to compile that one!

All you need to do now is to go into a new directory and use npm to install the modules:

mkdir somedir
cd somedir
npm install serialport

The result will be a node_modles directory containing the packages with their compiled native code!

 

Have fun!

Posted by & filed under Coding.

Today was quite an interesting day at a customers site. I was asked by a colleague to help with an implementation of a new component. Now, that’s not the interesting part really.

He already had developed a bit of code but was unsure how to integrate the classes he wrote. The implementation is based on an interface specification that is still under development and not complete at all.
His approach was to implement the server (will only be used as a simulator) and the client (the really important part) together and tested them by starting both simultaneously.

First he explained what he tried to do, and where the problems where when I asked about unit test. Now, we’re a scrum team, and we do tests. Not always test first, but the definition of done requires tests.

Starting from scratch

To start with, we concentrated on the client and we decided to go test first this time. Over the course of the day, we developed component by component, starting from the smallest parts to components that are composed by those. We added interfaces to add abstractions, added mocks and tests.
The code ended up being quite straight forward and simple but we couldn’t really reuse too much of what my colleague produced up front.

Lessons learned

My colleague was often unsure about how to do tests, and many times had difficulties writing them (as h e was doing them after the code mostly). Over the course of the day, I could show him how by example of how the design developed and how it we could write the code in a test first approach.

The nicest part was, when we went for a coffee in the afternoon, having spent almost the full working day writing this piece of code. My colleague something along the lines:

“Yes, it really helps to if you write the tests first. It’s a lot easier to write them and it makes the software design nice!”

This day was pretty exhausting and I didn’t finished what I planed to, but that was made up by the that sentence. I hope that was day of change for us!

Posted by & filed under OpenROV.

So far, if you where joining the OpenROV project, you had get a BeagleBone and install a standard Ubuntu disk image on the SD card.
Once you had your base OS, you had to compile  NodeJS yourself (that takes quite a while on a BeagleBone), get the OpenROV code and set everything up yourself.

A few days ago, I started to look into building a custom image that would contain everything ready set up. Based on the scripts that are used to build the demo Image and the project-rootstock by the Ubuntu team, I was able to setup a fully automated image building script. This includes:
- Getting and building NodeJS (currently v0.8.11) with a cross compiler
- Getting and preparing the OpenROV Software
- Getting and building mjpg-streamer for the BeagleBone (tool that will be used to do the video streaming)
- Building the root filesystem with all the basic Ubuntu packages (and a few more)
- Adding the cross compiled NodeJS  to the imge

The output of the script is an ziped up file containing the root filesystem, boot image and scripts to create a sd-card.

The last unsolved part so far is, how to get the NodeJS packages (express, serialport and socket.io) accross. Right  now you need to connect the BB to the internet the first time and install the packages manually (altough I tried to automate that by getting all the dependencies into a  special cache folder, moving that to the image and installing things from there, but that doesn’t work yet).

What you need is a (at least basic) Ubuntu installation and a clone of the following git repo: http://github.com/codewithpassion/openrov-image.

The first time you need to run the ‘setup-system.sh’ as root/sudo. That will install all the needed packages for cross-compiling and setting up the image.
To start the building process, you simply do: ./build.sh.
This will get all the things needed from git (NodeJS, my branch of the omap-image-builder and project-rootstock) and start the image building process.
Depending on your internet connection and machine performance, building the image can be a lengthy process (like one hour or so).
As I’m testing and developing that on a remote virtual machine (on Windows Azure), I use ‘nohup ./build.sh &’ to execute the process. This way, the process doesn’t stop if I should disconnect and I get all the outhput appended to the file nohup.log.

You can find the first Image here:

http://wp.nu/openrov-image-0

For more information on how to use the image, checkout the readme on github:

https://github.com/codewithpassion/openrov-image#get-and-install-the-openrov-disk-image

Posted by & filed under OpenROV.

Here are some findings on finding out what o-rings I have to use and what size I have to make my discs for the end caps of my ROV.

Not very structured, but hopefully useful for someone.

It seems like you get imperial o-rings in Europe too, at least with the o-ring specialists.
so, according to a catalog with instructions on what you have to look after, you can stretch or compress (nitril) o-rings by 5% of the ID. so, to go with a #153 (ID 88.57mm / width 2.62mm) should work.
They say too that the flute should be 2.1mm for the 2.62mm O-Rings.

It seems (by measuring with a ruler, so not really the best) my tube has actually an ID of 92mm..

For my tube, with 92mm ID that means that I would need the smaller disc to be 87.8mm.
That should still work with the 88.57mm ID O-RIng (#153).

The alternative is the 85mm /2mm width.
That has a flute depth of 1.7mm
that would give me a inner disc size of 88.6mm

As they recommend that you use (for o-rings that have to seal on their ‘outside’) the next smaller one oring of the ID of the o-ring is bigger that your piece where you put the o-ring on.

So, i think, I will go for the 85ID/2mm width.

Thats the document, sorry, its german.
http://www.ntkd.ch/pdf/Prosp_O-Ringe_deu.pdf

Still learning loads of new stuff I never ever thought about :)

Posted by & filed under Coding.

On SparkFun I saw recently the digital compass module HMC6352. You can connect it through I2C, a bus that both, BeagleBone and Arduino ‘speak’.

The SparkFun breakout board is very easy to connect, VCC (it works on 2.7 to 5.2 volts), GND and the two I2C wires.

 

1st attempt: BeagleBone

My first try was to hook it up on the P9 pins 17 and 18 of the BeagleBone. Once connected, I followed the example to connect an accelerometer to BeagleBone.
To check that your module works, you need the i2ctools package from Ubuntu. Then you can check with the ‘i2cdetect -y -r 1′ command  what devices are connected to the bus (if you have connected it to the I2C bus number 1).

The compass module should be on the address 0×42. But, if you connect it to the BeagleBone just as I did, It won’t work… The problem is the power level of the I2C bus. Even tough I2C is a standard, different devices work on different voltages. If you connect the HMC6352 to 3.3V, it will use that voltage on I2C too. But the BeagleBone expects 1.8V… No luck…

 

2nd attempt: Arduino

To connect I2C to Arduino, you use the pins A5 and A4 (top two pins on the right). Once the connection was changed, I incorporated the code from this example into the OpenROV Arduino code, and after flashing, it printed the heading to the serial console.

I have to clean up the integration of the compass code into the Arduino code and then I will upload it to GitHub.

 

Posted by & filed under OpenROV.

Building an OpenROV includes bending some acrylic sheet. There are some professional solutions called heat strip bender. Other people bend using a heat gun and I did test bending using a propane soldering torch.

Yesterday, Christopher Plymire posted on the OpenROV forum about building a simple strip heater using constant resistant wire. Having seen that, and having seen such wire in a local electronics store, I went and bought some. I didn’t know what diameter to use so I just bought 0.15mm (about AWG35) wire. But, beside a wire, you need a power supply. Now, Christopher mentioned you could use a PC power supply. That’s easy, having one lying around…

Using a PC power supply

If you look around, many people use spare PC power supplies for all sorts of things. To actually use an ATX power supply, you need to pull the (small diameter) green wire to ground. That’s what happens if you press the power button anyway. Keep in mind to do that without the main cord connected! Once you flip the switch on the power supply, you will find that you get 12V+ between the yellow and black line (black being ground). On various tutorials they tell you to actually put a device (or a resistor) on one of the outlets as the power supply could be damaged if the 5V line doesn’t draw anything.

 

Building the strip heater

I don’t want a strip heater that works till eternity. So, I used a slab of wood, two screws and some masking tape and tinfoil.

The screws are about 16 cm apart, just a bit larger than the body of the ROV. The tinfoil is used to protect the wood from the heat and to reflect it at the same time.

The resistance wire is wrapped around the screws once or twice and soldered to the cable coming from the power supply. (I had to solder it because my wire is coated and wouldn’t deliver the current otherwise. To connect the wire to the power supply, I used a standard extension cord wire I had laying around and as you see in the background, I just plug it into one of the drive connectors.

Once I switch on the power supply, the wire extends in length quite a bit, so I just pull it straight again and attach some sticky tape to fix the wire to the wood. Pretty simple, but works. The wire burnt through 2 times, but I think it was because it was tied around the screw at that point before for testing.

 

The bending

As described on the Wiki, I etched a line on the side of the bend of the acrylic sheet. I made a little mark on the side where the bend has to be so I can position the hot wire. 

The picture above shows my test bend with white acrylic. I had to heat the acrylic for about 3 or 4 minutes to make it slightly bending as you can see it on the picture. After that, I let it heat for about two more minutes, then, I took it off the heat strip and bent it by hand a bit more than 90°. If you let go, it will spring back a little bit and it doesn’t hurt if the sides have a little bit of tension.

Again, this is my test piece, the one is blue, but I didn’t take pictures during the bending.

But here’s the finished shell:
 

Posted by & filed under Coding, OpenROV.

Yesterday I had a great chat with two of the main drivers behind the OpenROV project. It’s an Open Source hardware (and Software) project with the goal to build an affordable, remote controlled, underwater vehicle. People all over the world should be enabled to do ‘citizens science’ while exploring underwater environments at their doorstep or just have fun with it.

As it’s one can only really protect what he knows and not everyone is able or willing to learn scuba diving, it’s important that there is a way to learn about what is under the surface of the local bodies of water.

The OpenROV project first emerged as a pet project of Eric Stackpole. He built the first versions of the ROV. Over time, other people joined and it was decided to put the design and build instructions freely available on the internet.

The OpenROV project got mentioned on twitter and they setup a Kickstarter project. With this publicity the followers came streaming in. Currently almost 1000 people registered on the forums.

But there was a drawback as well. More people means more questions, more inquiries on how to build a ROV.
There are some instructions available, there is a BOM (book of materials), the software that powers the ROV, the schematics for the electronics and the CAD files for the laser cutting of the body are on GitHub. But it is still quite hard to build your own and probably even harder to actively support the project.

Since a few weeks, we finally have a Wiki and instructions have been added by people from the community. Nevertheless, some crucial information are missing.

In our talk on Google+ yesterday we discussed how to go forward. Eric isn’t very familiar with Open Source yet, he’s a very talented engineer, but not so much around other open source projects as most of them are in the world of software.

What is important for an open source project

The main point that came up was, that the documentation for building a ROV isn’t complete yet because some things are not yet decided. Another point is, that the original project team would like to have a very complete documentation when they publish. Mind you, in this type of open source project, documentation should be looked at as the code in a ‘traditional’ open source software project.

Now, in my opinion, the most important thing is, to put whatever you have out there. Even if it’s only a few lines of text or an image. People are imaginative and they will hopefully figure it out if you can give them some hints. And, more important, hopefully they will improve your documentation and add their findings.

What we decided

In the discussion, me and Simone (another active ROV builder from Belgium) suggested that whatever information is there, even if it is not complete or probably not the best possible solution, should be put on the Wiki.
The decisions that were taken should be put on there as well, if possible, with a little explanation why a given solution was chosen over another one.
The community will hopefully sort out the rest!

Conclusion

So, if you are looking to set up an open source hardware project consider this:
- Communication, communication, communication
- put whatever you have on a wiki or other type of community editable site
- if something is not the best solution or your not sure about some piece, mark it as such! Wikipedia does the same if an article is a stub! The community will hopefully sort it out
- don’t be afraid, if you announced the project as open source and use one of the standard licenses, it’s most probably stated that, whatever is there, comes without guarantee

Hope that helps you to make the step and go public with your great project!

Posted by & filed under OpenROV.

During a Google Hangout session between Eric, David, Simone and myself about OpenROV we briefly discussed the possibilities of using RS-485 for the communication from the top side to the ROV. According to Eric, RS-485 is used for communication in scientific ROVs too, so why not go that route?

I already ordered some parts from SparkFun to test my idea, the parts I ordered are:  USB to RS-485 Converter for the topside and the RS-485 Breakout for the ROV.

The breakout board offers a UART interface that I will connect to one of the 4 UART ports of the BeagleBone. This will act basically as a converter between UART and RS-485.
The USB converter is connected to the laptop via a USB cable.

The twisted pair cable runs between the the breakout board and the USB converter.

The USB converter will show up as a ‘virtual’ COM port in Windows (or any other compatible OS).
To make it possible to use TCP/IP for the communication between the topside and ROV, we will need the Point to Point Protocol as it was used ‘in the old days’ when you dialed-up into your favorite BBS or later to the Internet.

On the ROV, this can be done running the PPPD (Point to Point Protocol Deamon).
On Windows by using a good old dail-up connection as you would with a modem (that would work on Linux or OSX too).

PPPD and the Windows dailup connection will negotiate over capabilities and finally, setup a TCP/IP connection (maybe we will need to run a DHCP server on the BeagleBone, not sure yet).

From there you take it as it you where connected via Ethernet.

So much about the theory. I’ll put it to the test once I’ve got the parts from SparkFun.

 

Posted by & filed under OpenROV.

I finally got around to assemble (no gluing yet) part of the ROVs body.


As I had an issue with the laser cutting and din’t had enough blue acrylic spare, some parts are white.