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:
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.
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.
Click for full size image:
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.
3 thoughts on “OpenWave : Development of an Open-Source and Low-cost wave sensor”
I’ve came across your project since I’m trying to implement the same thing using a GY-521 sensor.
First of all I’d like to thank you for sharing your journey of developing such a sensor.
Your results look pretty good and I wasn’t able to reproduce them myself.
As you’ve mentioned in your posts the integration error is a pain to deal with.
In your test results you use a pretty high angular velocity for your rotary arm, have you tried with lower velocities, are the results you obtain as good as the ones with the ‘fast’ rotating arm?
That would give a more realistic view since waves most of the time do not have such a short period.
https://github.com/wartek69/SeaConditionMonitor/ contains the code I’ve wrote for my project, it’s based on your code and I’m kind of surprised why I cannot reproduce your results. The only difference between your solution and mine is that I record the data by manually moving the accelerometer instead of using a rotary arm like you do. However I do not think this should give this big of a difference in the results. The data processing steps I’ve implemented are
1) filter the data using a moving average filter
2) Integrate the filtered data, detrend the velocity signal before integrating it to get the locations. I also detrend the location measurements to remove the bias term from the signal.
Is there something I’m missing or am too blind to see?
Did you have to finetune your filter parameters for each test?
Once I had the vertical acceleration to displacement script working, I could use it on any set of test data and get very similar results. Fine tuning parameters for individual data sets would be cheating!
As for exactly how this script works, I can’t really remember since I wrote it so long ago. If you visit this folder from the OpenWave repo and look at the script openwave.py, all the info is in there. If you run “python2 openwave.py peak” is will run the alogrithm using peak detection on a set of sample data (also in the repo). That is the algoritm working on several sets of data and you could add in your own data to see how our results differ. From looking at the script there, one thing that is does that you did not mention in your message is, it breaks the data into chunks based on zero crossing or peaks (script as arguments for both types). This limits the integral runaway by only integrating for a maximum time that is roughly 1/f of the lowest frequency wave being measured. Remember that even detrending data will not prevent this runaway. Detrending just removes positive or negative trends and makes the average slope of the waveform 0. The amplitude of that waveform could still be crazy (from my understanding).
Another point to remember is that what we are trying to do here already exists a as commercial product and research groups have been able to use arduinos etc. to get this stuff working. I agree with your point about the rotation speed not matching ocean wave frequencies so maybe this particular algorithm wouldn’t work for slower frequencies, I wasn’t really able to test for that with the setup I had. Regardless there is an alogithm out there that can do it is my point! Unfortunately no one has open sourced this data yet. I really think an open source wave sensor would be a great contribution to the world. They would become as commonplace as temperature sensors on data buoys.
Best of luck with the project,
I’ve wrote something similar:
Estimating wave height from IMU accelerometer on a moving boat