4
\$\begingroup\$

I am dealing with the problem of estimation the swimmer's velocity. In the same time data from IMU sensor and tethered system are acquired. Data from tethered system are reference data. From IMU sensor acceleration, angular velocity and strength magnetic field data were acquired. IMU sensor was placed on lower back.

Example data from tethered system for the one trial:

enter image description here

The best velocity from IMU that I estimate was:

enter image description here

and for the comparison purpose:

enter image description here

My questions are:

  1. As it can be seen, the curves are not overlap exactly. Is it possible to improve the results for IMU sensor?
  2. Do you have any idea how to pre-process data from IMU?
  3. How improve data from tethered system?
\$\endgroup\$
9
  • 2
    \$\begingroup\$ The problem with acceleration is that it's impossible to determine the absolute velocity unless you start from a known initial state. \$\endgroup\$
    – Ignacio Vazquez-Abrams
    Commented Mar 19, 2015 at 15:51
  • \$\begingroup\$ increase the sensitivity of your IMU. It's rise time seems too slow or something. \$\endgroup\$
    – KyranF
    Commented Mar 19, 2015 at 15:55
  • \$\begingroup\$ Another problem with accelerometers is their noisy behavior, that is rendering the velocity estimation nearly impossible because of quickly accumulated error. Yo really need to consider additional sensors. \$\endgroup\$
    – Eugene Sh.
    Commented Mar 19, 2015 at 16:18
  • \$\begingroup\$ I'd like to see the acceleration data. If you show me that and give me the actual part number of the sensor I can give you a better idea on settings for optimal collection given your scenario and possible digital filtering options. \$\endgroup\$
    – mcmiln
    Commented Mar 19, 2015 at 17:19
  • \$\begingroup\$ Thank you for inspiring comments. @Ignacio, the swimmer before start swimming stay still in water. I am aware that it is not possible to be in stationary state in water but that is the peculiarity of this problem. \$\endgroup\$
    – cabal
    Commented Mar 21, 2015 at 16:12

2 Answers 2

Reset to default
2
\$\begingroup\$

So, first off, after looking at the accel data you sent over it is crucial to consider what the data may represent. It would seem that given the timescale, your device is picking up a very repetitive movement. You can tell based on the repeating high peaks. Now one question is how is this being worn. What I am guessing is that as the swimmer comes up and down or turns left and right, they experience this motion. This motion will manifest with different frequencies based on where it is mounted and thus the coupling to the body. This coupling determines data accuracy, and general tethering of all systems. Since this is not a rigid body, you will experience time delays and force dissipation. On skin, clothes, hair, etc, these give you different filter frequencies.

If you wear this as a belt lets say, you will want to filter out frequencies corresponding to it dragging across your skin and the fabric moving back and forth. This oscillating motion would likely show up as more shifting acceleration than you would see from a general swimmer. You will benefit from a moving average filter. In addition, the large repetitive spikes are probably from smacking on the surface of the water as a quick guess. Perform a median filter on the accel data to rid it of these motions which do not show user speed. Then get the velocity, which will be much cleaner.

These things will not improve the system, but rather knowing how the system manifests in data is more valuable. You can predict why the system is not tethered based on the mounting and filter the data of high frequency noise. Any further improvements could be done in miniaturization or more mechanical filtering with the casing. Feel free to respond with more specifics on the system if you would like more info. Hope this helps.

\$\endgroup\$
0
\$\begingroup\$

I would not expect the tethered system to match the swimmer; they are not tightly coupled. Remove your IMU from the swimmer and build an out of the water test fixture with a motion/velocity profile that's known fairly precisely. Attach the IMU to the fixture to validate that it's reading the known trajectory/speed.

There's nothing wrong with integrating the accelerometer signals; integrating smooths the high frequency noise. The issue as @Ignacio said is the initial alignment of your system - the gyros. You need to initialize and maintain a local vertical reference frame to resolve your integrated accelerometer vectors.

\$\endgroup\$
2
  • \$\begingroup\$ I am agree that tethered system can cause some problems with calculating swimming velocity. But I needed reference signal to test my method with existing ones. Now I know that tethered system is not perfect method. But my problem is to estimate instantaneous velocity of the swimmer and this method – as reference method – is available for me. As you suggested I tested my method of velocity estimation out of the water. First test I performed for runner where reference velocity signal are acquired from sports radar (Stalker Pro) and results were good i.e. goodness of fit was high. \$\endgroup\$
    – cabal
    Commented Mar 21, 2015 at 16:57
  • \$\begingroup\$ I agree that integration of acceleration is hard problem but there are some methods to deal with this problem. One of them is ZUPT (Zero Velocity Update). The other one is method where additional sensors such as GPSs or video cameras are used. But these methods are not applicable for estimation of swimmer’s velocity. My idea is to apply de-trending method for non-linear and non-stationary signals. It worked out of the water but field in the water. But I am not sure that my method is weak or reference signal is not perfect. What is your opinion? \$\endgroup\$
    – cabal
    Commented Mar 21, 2015 at 16:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.