Signal segmentation

[LaBoris]

Hello, I have this signal that represents calculated Euler Angles (Green - Pitch-Roll, Blue - Roll, Red - Pitch) and each "box" bordered with black lines contains specific activity performed 3 times in a row. What I want to achieve is to segment each activity and process it afterwards (calculate signal energy, find peaks etc.) could you recommend me an approach for this?  

Thank you for any advice!

[Bob_Schor]

A very nice picture, along with nice lines.  With scissors, cut the pictures along the black lines, then analyze the colored (green, blue, red) lines however you wish.

Where is the LabVIEW in this question?  Or is there any?  There are many conventions for Euler Angles.  I know about Roll and Pitch, but have never heard of Pitch-Roll.  Are you measuring velocity or orientation (with respect to what?)?  Without know what you did, where and how the data were obtained, and what you really want to do, it is difficult to make many suggestions.  However, if you want to do this with LabVIEW, then learn LabVIEW, and phrase the question in terms of LabVIEW (such as define "signal" and how you got the "calculated Euler Angles").

Bob Schor

[LaBoris]

Hello Bob, I am sorry for my vague question interpretation so I will try to be more specific.

this Diagram describes how am I obtaining the Roll, Pitch, Pitch - Roll Data, after that, I simply plot them and get the previous graph.

 

 I have experimented with this code from (https://forums.ni.com/t5/LabVIEW/Trigger-amp-Gate-to-split-waveform-into-cycles/m-p/1925667/highligh...). I input data.txt which corresponds to time and calculated Pitch - Roll and It works pretty well, All I want is to change the timebase of segmented peaks to correspond the time base of the input signal.

I added the modified snippet and the input data.

[Kevin_Price]

I don't have LV2019 and can't view the snippet.  But just by quick visual inspection, those graphs don't seem to represent what I *think* you're claiming.

I think you're saying that:

Blue plot = Roll angle

Red plot = Pitch angle

Green plot = the difference (Pitch angle - Roll angle)

Looking at the different sections, it's pretty clear in at least some of them that the Green plot is *not* the result of subtracting the Blue from the Red.   Look at "Right Tilt".   Look at "Back Bend".  There's no way.

-Kevin P

[LaBoris]

Hello Kevin, Green line represents the sum of the Pitch and Roll squared under the square root. That's why it doesn't go to negative values. Sorry If I wrongly described it.

Boris

[Kevin_Price]

No prob, that's why I emphasized that it was what I *thought* you meant.   Now I can look at the plots and nod along, they make sense now.

Can you write up a more complete description of your problem?  I looked over the thread you linked, but it didn't really give me a lot of insight.

Are you trying to figure out how to *identify* the segment endpoints and meaning?  That might be a hard problem to solve.  Especially if you're working only with the single resultant value as shown in your .txt file. 

    Whenever possible, it's often *much* more straightforward to find a way to *generate* identifying information that you collect alongside your regular data.  However, judging by the diagram you posted, it looks like you may not have any possibilities there.

-Kevin P

[Bob_Schor]

Aha!  I was wondering if a Triaxial Accelerometer was in use here.  I was also wondering if quaternions (which not that many understand) were going to make an appearance (I couldn't think of any other reason why Euler Angles would pop up).

Several years ago, some students came to me with a triaxial accelerometer and wanted to make some measurements of muscle twitching.  This was not as fancy a device as your chip.  They didn't understand how to calibrate their device (the published offset and gain (volts/g)) for each axis had a ±10% range on the values!).  I had them stick with X, Y, and Z accelerations induced by the (relatively-constant) orientation of the chip in space and the (relatively-high-frequency) transient signal due to the underlying muscle twitch.

I think the place you need advice and counseling is on the first part of this Project, collecting the data and getting appropriate data back.  You have a tri-axial accelerometer, but are using only using two dimensions in your analysis, so it is bound to be, well, maybe not "meaningless", but certainly "highly questionable".

If I were giving advice, I'd say you want the "raw" data (X, Y, Z, three axes of gyro data, possibly mag data) and do your own computation.  Be sure to include a "Calibration run" of the instrument with each data run.

Bob Schor

[LaBoris]

My problem is in recognition of movements. If you compare the "Forward Tilt" and "90 ° Degree bend" movements, they have the same green and red (Pitch - Roll, Roll) lines and with classic thresholds the recognition of these two movements conflicts. Therefore, I decided to calculate for each peak signal energy and compare it, the assumption is that 90 ° Front bend will have greater signal energy.

And as you say, unfortunately, it is a motion that cannot be generated in advance with information that could be used to identify it.

[LaBoris]

Hello Bob, I believe working with an accelerometer is sometimes really frustrating but BNO055 is an inertial measurement unit that encapsulates all mentioned: 3-axial accelerometer, 3-axis gyroscope, and 3-axis magnetometer. The BNO055 even has an internal chip that calculates quaternions which I use as input data. Calibration of all three modalities is performed on the transmitter side. Therefore, I think that the accuracy of the input data is sufficient.

The reason why I use only two of the three Euler angles is that when analyzing the aforementioned front bend and forward tilt, Yaw does not apply. (Check out the blue line - PS: The first big negative spike was a motion artifact in the forward tilt).

[Kevin_Price]

---

@LaBoris wrote:

The reason why I use only two of the three Euler angles is that when analyzing the aforementioned front bend and forward tilt, Yaw does not apply. (Check out the blue line - PS: The first big negative spike was a motion artifact in the forward tilt).

But see, that's exactly part of the problem.  *You* seem to somehow know that was a motion artifact that can be ignored.  How will you design an automatic algorithm that can know what to believe and what to ignore?  What about the wide variation in amplitudes you might get when the motions are performed faster and slower?   What about motions that are combinations of some of the available options?

This whole thing sounds like it calls out for some kind of fuzzy logic approach, based on *all* available raw data, and lots of learning runs to seed the network.  And I can't offer much more help in that regard because frankly, such an approach is beyond my present knowledge and ability.

-Kevin P