OpenWave – Post #3

To give a quick summary of where I’m at with this project, I’ve got my breadboard circuit attached to the end of a rotating arm and it’s streaming data back to my PC. I’ve performed some basic analysis on this data and have double integrated the z-axis acceleration to get displacement and this displacement value roughly matches the length of the rotating arm.

Breadboard Circuit On Rotating Arm

So just as a recap, the breadboard contains a teensy 3.6, a BNO55 9DOF IMU sensor and a serial bluetooth adapter. At the moment the only values I have streaming to my computer are linear acceleration for the x,y and z axis. In the image above, the z axis is perpendicular to the surface of the BNO55 breakout board. I’ve chosen the z-axis to perform some signal analysis on as it is the vertical displacement I’m interested in. Before we get in to the signal analysis, check out this video of the arm rotating:

It’s useful to first see how the breadboard moves as the rotating arm rotates. It doesn’t stay perfectly horizontal which is actually a good thing as this means it is slightly more accurate a representation of a real life data buoy.

First lets take a look at the z-axis linear acceleration:

Z-axis linear acceleration graph

This graph contains acceleration data from about four and a half rotations. The good news is you an see a clear periodic element to the data which does roughly coincide with how long the rotations take (for this set of data each full rotation was around 4 seconds). It’s a bit puzzling the way the acceleration dips a bit before increasing and then dropping down to around -4m/s^2. One possible explanation is this occurs when the IMU is near the top of the rotation, the mount does not stay completely horizontal as there is some friction with the rotating arm. This causes the rotating mount to rather quickly flick from one position to another when near the top of a rotation. This flicking action may momentary cancel out the z-acceleration before the imu starts to properly descend once again. This action can be seen in the video above. Another contributing factor may be that the rotating arm is weighted in an unbalanced way. If the counterweight is a bit heavier than the breadboard it would have a slight catapult effect when the IMU is near the top part of the rotation.

In the graph above, the minima where the acceleration drops to around -4m/s^2 represents the IMU at the lowest part of the rotation (6 o clock on a clock dial).

So if we integrate from one minima to a neighboring one this will give us the instantaneous velocity for each point in one rotation. For my displacement data experiment, I took the acceleration from one half rotation which was from the 6 o clock position to the 12 o clock position. In reality I was a bit off so it’s a bit more than one half but it doesn’t really matter as you will see in the graphs below.

If we integrate this velocity once more, displacement can be obtained.

See below for the graphs of acceleration, velocity and displacement:

Graph of Z-axis acceleration for one half rotation

Graph of z-axis velocity

Z-Axis Displacement during half rotation

This initial test has shown quite encouraging results. The length of the rotating arm is 1.5 meters and the IMU is mounted right at the end of the arm. This means going from the 6 o clock position to the 12 o clock position, the IMU will travel through a vertical distance of 1.5 meters which you can see is roughly the maximum displacement on the displacement graph.

The Integration Problem:

Example of integration drift with velocity measurement

From the graph above you can see the issue related to absolute 3d position tracking with IMU sensors. The fact that to get velocity you have to integrate an acceleration measurement means that even tiny errors will accumulate. Then performing another integration of the velocity to get displacement means that any errors in the acceleration measurement are integrated twice and so the error accumulates in an exponential fashion.  As a result, the general consensus is that IMU devices are not suitable for absolute 3d position tracking.

The reason why wave sensors can get away with this is they use a statistical measurement approach. Measuring the height of a single wave may have a relatively large error margin but measuring the heights of say 1000 waves and reporting the significant or average wave height has been achieved by many commercial wave sensors. One step needed is to periodically reset the integration counter. In the first graph in this post of z-axis acceleration, the minima stand out on the graph as easy spots to reset the integration counter. This means that any error that accumulates would only have around 4 seconds to do so.

Next Steps:

It’s early days in terms of algorithm development. This post is a quick record of some analysis on the first data set of linear acceleration from the rotating arm. For the next week I will try to develop the algorithms further, Hopefully to the point where the starting point is a set of linear acceleration data and a program that can just spit out a value for maximum vertical displacement. Wave direction is another important parameter and the next few days will be spent thinking about how to approach that problem. Once these basics are taken care off, I can start to introduce statistical analysis and frequency domain representations of the data.

Posted in Uncategorized | Leave a comment

OpenWave – Post #2

Some decent progress has been made since the last blog post. See the image of the breadboard below which shows the current state of the electronics:

The small blue pcb with the four mounting holes is the BNO55 breakout board from adafruit. The vertical standing pcb is a serial bluetooth adapter and the green pcb on the far right is a teensy 3.6. The whole thing is powered by 4AAA batteries because I’m intending to put this on the end of a rotating stick and don’t want power cables getting in the way.

The Teensy communicates with the BNO55 via I2C and also can send serial data via one of it’s UART ports which is connected to the bluetooth serial link.

At the moment I’ve got some euler values streaming via bluetooth serial to my computer as an initial test:

I had a motor in my parts bin that has a built-in gearbox and a good amount of torque. The issue was connecting the shaft of the motor to the rotating arm. In the end a laser cut bracket made out of acrylic did the job and allowed me to make a good connection between the motor shaft and the rotating arm as seen here:

The rotating arm is 1.5 metres in length, that seemed to be about the longest the motor could handle and it also fits in my room which is nice. For testing that the motor had enough torque I taped 100g weights to either end of the arm and thankfully the motor was still able to rotate the arm without too much difficulty. See the video below for the rotating arm in action:

As you can see from the video, the speed of the arm is not constant as it rotates around. When the arm is vertical or approaching vertical the law of the lever makes things a bit easier on the motor so it is able to accelerate a bit, when the arm is horizontal that is the hardest part of the cycle for the motor and so the arm slows down. This isn’t an issue and it probably is a closer analogue to a data buoy on a wave than if the acceleration was kept constant all the way around.

The end goal is to have the breadboard circuit with the batteries, bluetooth adapter, teensy and BNO55 attached to the rotating arm. The one detail that will require extra attention is that the electronics need to stay more or less horizontal as the arm rotates. This will require some kind of mount that can rotate freely and has a bit of weight towards the bottom so as the arm rotates the mount stays horizontal. Having the electronics rotate with the arm would make the IMU calculations way more difficult. I’m not saying it’s impossible, it would just add a layer of complication that is totally unnecessary for the current application. Once the electronics is mounted to the arm I can start thinking about how to approach the software for the project. My thoughts at the moment are that it might be easier to get the raw IMU data for a couple of rotations, store that in a CSV file on my computer and try to develop some algorithms using that data. Once I get something working on the PC I can then go back and try to run it on the microcontroller. I think this approach will be fastest but I’ll give it more thought over the next few days.

Posted in Uncategorized | Leave a comment

OpenWave : Development of an Open-Source and Low-cost wave sensor

Post #1 (2nd February 2019)

This blog post will document the process of developing a wave sensor which I’m calling OpenWave for use on data buoys such as the one shown below:

pml_buoy_1

Ocean wave measurement has a wide range of applications including weather forecast model validation, warning systems for extreme weather events, testing a locations suitability for wave energy harvesting as well as wave measurement for the design specification of sea structures such as oil rigs, piers, lighthouses etc.

There are currently several commercially available wave sensors on the market. The issue is they are prohibitively expensive, costing around ten thousand euros which is too much for many academic and commercial uses. The hardware of the sensors is relatively inexpensive but the proprietary algorithms developed by the manufacturers effectively allows them to set the price. The goal of this project is to develop a wave sensor and make the hardware and software open-source.

I have written a literature review which investigates the academic articles and general information surrounding IMU wave sensing devices. Several people have written academic articles detailing their use of low-cost 9DOF(Degrees of Freedom) devices to measure waves, proving that it is indeed possible. 9DOF IMU sensors contain three seperate sensors, an accelerometer, a gyroscope and a magnetometer.  The accelerometer measures acceleration, the gyroscope measures angular velocity and the magnetometer measures the earths magnetic field. Each of these sensors is sensitive to 3 separate axes giving a total of 9 axes of measurement. A great video which goes into more detail about why 9 Degrees of Freedom are necessary for stable orientation measurement is available here. One study looking at low cost inertial wave measurement detailed a wave sensor made using an arduino and a cheap 9DOF IMU sensor and compared it to a commercially available sensor with extremely high cross correlation between both sensors. Unfortunately the people that performed this study only disclosed their results but kept the algorithms they used private. They have now gone on to sell a commercial product using the algorithms they developed. Which I think is actually quite encouraging for this project!

The literature review is available to view here.

Investigation of IMU sensing modules

After researching various 9DOF IMU modules available such as the MPU-6050 or the MPU-9250 it became clear that the sensor fusion was going to be an extremely laborious part of the project. Sensor fusion refers to combining the accelerometer, gyroscope and magnetometer data to allow for a stable AHRS (Attitude and Heading Reference System). An interesting development in recent years has been the inclusion of a DMP (Digital Motion Processor) in IMU chips. The idea being that some of the calculations required could be done on the IMU chip itself instead of having a separate processor do all of the sensor fusion. Both the MPU-6050 and the MPU-9250 include DMPs but they only perform sensor fusion on the accelerometer and gyroscope data, leaving the magnetometer data up to the external processor to handle. Then I came across a fairly new development, which is 9DOF modules with a built in arm processor that does all of the sensor fusion and spits out meaningful data over I2C. One such example is the BNO55 and it outputs the following data :

  • Absolute Orientation (Euler Vector, 100Hz) Three axis orientation data based on a 360° sphere
  • Absolute Orientation (Quaterion, 100Hz) Four point quaternion output for more accurate data manipulation
  • Angular Velocity Vector (100Hz) Three axis of ‘rotation speed’ in rad/s
  • Acceleration Vector (100Hz) Three axis of acceleration (gravity + linear motion) in m/s^2
  • Magnetic Field Strength Vector (20Hz) Three axis of magnetic field sensing in micro Tesla (uT)
  • Linear Acceleration Vector (100Hz) Three axis of linear acceleration data (acceleration minus gravity) in m/s^2
  • Gravity Vector (100Hz) Three axis of gravitational acceleration (minus any movement) in m/s^2
  • Temperature (1Hz) Ambient temperature in degrees celsius

Developing a wave sensor is going to be complicated enough without the added overhead of trying to manually implement kalman filters and perform sensor fusion on a seperate processor. The BNO55 will save a significant amount of software development time. Adafruit sell a breakout board for it which I have ordered and expect to arrive early next week.

Project Timeline:

I’ve spent the past few days researching various IMU modules and have settled on the BNO55. The breakout board has been purchased and will be here in the next few days. As the gantt chart below indicates I will use this time before the breakout arrives to prepare a rotating arm (like the one shown in image below) to aid in testing the wave measurement algorithms.

Example Image of Rotating Arm

Click for full size image:

gantt

Project Timeline Gantt Chart

The aim is to have the rotating arm built by the time the BNO55 breakout board arrives. This means I can get testing straight away. I’ve allowed one day for connecting the BNO55 to a processor, getting everything talking etc. From there the initial proof of concept algorithm development will begin which I’ve allowed one week for. This will include attempting to measure “wave height” which in this case should be the diameter of the rotating atm and also wave direction. These two initial parameters are just to make sure that the BNO55 is indeed capable of doing the job required. I’ll go into the rest of the timeline in the next post as at this early stage it is likely to change.

Posted in Uncategorized | Tagged , , , | Leave a comment

Laser Cutting Circuit Diagrams In Plywood Using Inkscape

image10

This circuit diagram was designed in Inkscape with all of the electrical symbols taken from the WikiMedia commons electrical symbol library. It’s got transistors, voltage sources, LEDs, resistors etc all in SVG format.

There are a few steps in Inkscape to convert a circuit diagram to something that can be laser cut.

Step 1: Convert everything to a path using the stroke to path option (found in path>stroke to path). Take a look at these pictures to get an idea of what this does.

Take these two images, they both look the same in normal view mode, but viewing them in ‘outline’ mode is effectively what the laser cutter works off.
stroke-no-stroke

Capture

 

This example is just a resistor taken from the wikimedia commons library and line attached to either end of the resistor. The lines are red just so you can differentiate them from the resistor. Notice in the stroke only image its a single line which is not what we want. We want to cut out the outline of the shape – the stroke to path option does this.

We’re not home free yet though – if you look at the stroke to path outline image you can see where the lines and resistor meet are still seperate entities. We want to combine them into a single line. This is done using the ‘union’ tool found in path>union. You can only select two items at a time to ‘union’ together so doing a whole circuit diagram is a little tedious. Take a look at the image below to see what the image looks like after the ‘union’ tool has been applied:

 

That’s it! circuit diagram is now good to laser cut. union-ex

 

 

 

 

 

 

 

 

Circuit diagram viewed in ‘outline’ mode:

diagram-outline-mode

 

Circuit diagram viewed in ‘normal’ mode:

diagram-normal

Click Here to download SVG of circuit diagram

Posted in how to, Inkscape, laser cutter | Tagged , , | Leave a comment