balandinodidonato / MyoMapper

Myo Mapper is an open-source application to map Myo armband data into OSC.
http://www.balandinodidonato.com/myomapper
47 stars 8 forks source link

Difference between Wiki, Feature Window and actual data #54

Open thebbg opened 5 years ago

thebbg commented 5 years ago

Hey Balandino,

I've started reusing the mapper a few months ago. I couldn't help but notice there are a few disparities between the information from the different platforms. I just tested everything out, basing my test on the Features window in the Myo Mapper V3. Everything was runned on macOS High Sierra, with updated myo's and the Myo Mapper V3.1.6.

The followings show up in the Features window but are absent from the wiki : -emg/raw/mavg -emg/scaled/abs/fod -emg/scaled/fod/mavg -emg/scaled/abs/mavg -emg/scaled/abs/mav/mavg -emg/scaled/abs/mav/fod/mavg

The following send no data to the specified address: -emg/scaled/abs/mav

The followings have data formated then what's specified on the wiki: -acceleration/raw/fod : from -128 to 127 instead of -16 to 16. Also wrong address in the wiki -acceleration/scaled/fod : range from -4 to 4 instead of 0 to 1 -acceleration/scaled/fod/mavg : the lowest value actually goes a bit lower than 0 -gyro/raw : maximums reach a bit higher than 2000 -gyro/scaled : maximums reach a bit higher than 2000 -gyro/scaled/abs : maximums reach a bit higher than 2000 -gyro/scaled/fod : range from -2.xx to 1.xx instead of 0 to 1 -gyro/scaled/mavg : the address is wrong on the wiki (aavg instead of mavg) -emg/raw/zcr : data is always positive -emg/raw/zcr/mavg : data is always positive -emg/scaled : some data reach a bit lower than 0 -emg/scaled/abs : some data reach a bit higher than 1 -emg/scaled/abs/max : some data reach a bit higher than 1 -emg/scaled/abs/fod : range is from -4 to 4 (might be good but it's not in the wiki so can't say for sure) -emg/scaled/abs/mav/fod : range from -2 to 2 instead of 0 to 1

There you have it. It's a bunch of small issues, but until there resolved, I hope this list will reduce the number of people trying to understand what is going on. At least all the raw data's work fine so that's a good start.

Also, I only tested with 1 myo connected as I saw there were issues with the data control if 2 myos were plugged (so other thread).

Finally, it could be interesting to add a formula or something of the kind in the wiki showing how each set of data is extracted. It could help using the said data. Just a suggestion though.

Cheers, thank for the app again. Despite the problems, it is a very useful tool!

balandinodidonato commented 5 years ago

Hi @thebbg thank you so much for this report! this is incredibly useful. I'm planning to get a bunch of issues sorted this week. At least I'll try. this is also valid for issue #50 .

I'll trying to get this done together with the windows release fixed. PS do you ming to give some thoughts on this issue: #55 :)

balandinodidonato commented 5 years ago

Hi @thebbg, I went through each of your comment and I found the following:

-acceleration/raw/fod : from -128 to 127 instead of -16 to 16. Also wrong address in the wiki

The address is now corrected but the values should be ok. Please could you give me a screenshot of a data visualisation or something?

-acceleration/scaled/fod : range from -4 to 4 instead of 0 to 1

on the wiki the range is wrong but I get as data range -1,1. The scaled values range is 0-1 it is pretty impossible that you would get higher numbers.

-acceleration/scaled/fod/mavg : the lowest value actually goes a bit lower than 0

Being the moving average of the above data it should be in the same range as above.

-gyro/raw : maximums reach a bit higher than 2000 What's the maximum value you registered? in what conditions? What was the movement? I also changed the scale, it should be fine now.

-gyro/scaled/fod : range from -2.xx to 1.xx instead of 0 to 1

This should be fixed in with the next release

-gyro/scaled/mavg : the address is wrong on the wiki (aavg instead of mavg) -emg/raw/zcr : data is always positive -emg/raw/zcr/mavg : data is always positive

fixed ;)

-emg/scaled : some data reach a bit lower than 0 In the next release this will be as -1, 1 and this will be fixed in the wiki. I do not register any data below 0 at the moment.

-emg/scaled/abs : some data reach a bit higher than 1 -emg/scaled/abs/max : some data reach a bit higher than 1 this is very odd. I did make changes for the next release and this should be fixed

-emg/scaled/abs/fod : range is from -4 to 4 (might be good but it's not in the wiki so can't say for sure) -emg/scaled/abs/mav/fod : range from -2 to 2 instead of 0 to 1

These will be fixed in the new release and they will be within -1,1

Finally, it could be interesting to add a formula or something of the kind in the wiki showing how each set of data is extracted. It could help using the said data. Just a suggestion though.

This might be very helpful I guess. I'll try to find some time for it :)

Thank you very much for all suggestions.

thebbg commented 5 years ago

Wow, that's quick!

For the test, I use the same procedure for all addresses. Started with an array of arrays that looked like this ( [3000, -3000], [3000, -3000], [3000, -3000], [3000, -3000], [3000, -3000], [3000, -3000], [3000, -3000],[3000, -3000] ).

Then I had a function scanning the data coming in and looking for minimums and maximum. Every new mins and max were recorded in the corresponding index in the original arrays. Then I dummy proofed every data, making all kind of gesture, from slow to fast and small to big. Don't think I would do gesture that big in performances, but it helps to know what the limits of the system were. The data I used in the previous post came from the results of those test. So for positions, only the first 3 arrays were changed, emgs used all of them and mavg's only the first one. I only reported the data collected from the array. So modification to it or anything.

I don't have much time today to check it out, but I can redo the test and send some screenshots. I'm working with Python 3.6 using the Pyo audio library, I can send you the patch with the results if you want to, or only screenshots.

For the values that went a bit higher than the supposed maximums, it never reach 2001 if we use the gyro for example, but it reached a bit higher than 2000, something like 2000,000234543524144, so it wasn't that much higher, but still was a bit. It was the same for pretty much the same for all of those I didn't give specific numbers, be it maximums or mimimums.

I can see you release v3.1.9 for macOS. I'll download it and run the test again tomorrow, will be back with the results, screenshot and I'll keep in memory all the data so you can have a look for yourself.

As for the formulas, I would be mostly curious about the way you calculate the velocity. I'm using it to detect movement and its working great, just sad that it stops working well with 2 myo's. Until the problem can be solved, I'm gonna try to implement it directly in my patch using raw datas, so if I had the same formula than you have that would be great, wouldn't need to recalibrate all of it :)

Thanks for you quick work. That is amazing! =D