Myo SDK MATLAB MEX Wrapper - Revision history

Mark at 04:03, 24 April 2016

2016-04-24T04:03:03Z

← Older revision		Revision as of 04:03, 24 April 2016
Line 111:		Line 111:
	'''Electromyography (EMG) Data'''		'''Electromyography (EMG) Data'''

	The Myo device also contains eight electromyography sensors from which an eight element array of signed eight bit integer intensity values is sampled in the <code>emg</code> data provided in the <code>onEmgData()</code> function. This data is sampled at 200Hz (5ms sample time) on the Myo device, but it is received by the Myo SDK in pairs of consecutive samples due to bandwidth limitations of the Bluetooth Smart protocol. Although the sampling of EMG data in its own time base suggests a straightforward process by which to validate this data, this fact slightly complicate the process.		The Myo device also contains eight electromyography sensors from which an eight element array of signed eight bit integer intensity values is sampled in the <code>emg</code> data provided in the <code>onEmgData()</code> function.

			<syntaxhighlight lang="c++" line inline>void onEmgData(myo::Myo myo, uint64_t timestamp, const int8_t* emg) {}</syntaxhighlight>

			This data is sampled at 200Hz (5ms sample time) on the Myo device, but it is received by the Myo SDK in pairs of consecutive samples due to bandwidth limitations of the Bluetooth Smart protocol. Although the sampling of EMG data in its own time base suggests a straightforward process by which to validate this data, this fact slightly complicate the process.

	The expected format for pairs of <code>emg</code> and <code>timestamp</code> data is,		The expected format for pairs of <code>emg</code> and <code>timestamp</code> data is,

Mark: /* Device Data */

2016-04-24T04:01:53Z

Device Data

Mark at 03:58, 24 April 2016

2016-04-24T03:58:54Z

← Older revision		Revision as of 03:58, 24 April 2016
Line 32:		Line 32:
	To provide some context for the content herein, here's a minimal example usage of the Myo SDK.		To provide some context for the content herein, here's a minimal example usage of the Myo SDK.

	<syntaxhighlight lang="c++">		<syntaxhighlight lang="c++" line>
	#include "myo/myo.hpp"		#include "myo/myo.hpp"

Line 71:		Line 71:
	The <code>myo::DeviceListener</code> class provides access to various device data including sensor data and device state updates. The following member functions of <code>myo::DeviceListener</code> provide access to this information.		The <code>myo::DeviceListener</code> class provides access to various device data including sensor data and device state updates. The following member functions of <code>myo::DeviceListener</code> provide access to this information.

	<~~pre~~>		<syntaxhighlight lang="c++" line>
	void onPair(myo::Myo* myo, uint64_t timestamp, FirmwareVersion firmwareVersion) {}		void onPair(myo::Myo* myo, uint64_t timestamp, FirmwareVersion firmwareVersion) {}

Line 103:		Line 103:

	void onWarmupCompleted(myo::Myo* myo, uint64_t timestamp, WarmupResult warmupResult) {}		void onWarmupCompleted(myo::Myo* myo, uint64_t timestamp, WarmupResult warmupResult) {}
	</~~pre~~>		</syntaxhighlight>

	The <code>on<data>Data()</code> functions provide access to new sensor data, whereas the other functions provide more general information, or meta data, relating to devices state. The former set of functions are the primary focus of data acquisition applications, and will be discussed further in this section,		The <code>on<data>Data()</code> functions provide access to new sensor data, whereas the other functions provide more general information, or meta data, relating to devices state. The former set of functions are the primary focus of data acquisition applications, and will be discussed further in this section,
Line 157:		Line 157:
	A stripped down implementation of this technique may store the <code>myo::Myo*</code> pointers in a <code>std::vector</code> of, and rely on a single member function to performs both lookup of a new Myo from the vector and push back of a new Myo onto the vector. For example, consider the following.		A stripped down implementation of this technique may store the <code>myo::Myo*</code> pointers in a <code>std::vector</code> of, and rely on a single member function to performs both lookup of a new Myo from the vector and push back of a new Myo onto the vector. For example, consider the following.

	<~~pre~~>		<syntaxhighlight lang="c++" line>
	class MyDataCollector : public myo::DeviceListener		class MyDataCollector : public myo::DeviceListener
	{		{
Line 173:		Line 173:
	}		}
	};		};
	</~~pre~~>		</syntaxhighlight>

	== Device Listener Class ==		== Device Listener Class ==

Mark: /* Basic Implementation */ switch code lexer

2016-04-24T03:57:42Z

Basic Implementation: switch code lexer

← Older revision		Revision as of 03:57, 24 April 2016
Line 34:		Line 34:
	<syntaxhighlight lang="c++">		<syntaxhighlight lang="c++">
	#include "myo/myo.hpp"		#include "myo/myo.hpp"
	/*
	class MyDataCollector : public myo::DeviceListener		class MyDataCollector : public myo::DeviceListener
	{		{
Line 56:		Line 56:

	return 0;		return 0;
	}*/		}
	</syntaxhighlight>		</syntaxhighlight>

Mark at 03:55, 24 April 2016

2016-04-24T03:55:42Z

← Older revision		Revision as of 03:55, 24 April 2016
Line 32:		Line 32:
	To provide some context for the content herein, here's a minimal example usage of the Myo SDK.		To provide some context for the content herein, here's a minimal example usage of the Myo SDK.

	<syntaxhighlight lang="~~cpp~~">		<syntaxhighlight lang="c++">
	#include "myo/myo.hpp"		#include "myo/myo.hpp"
	/*		/*

Mark at 03:52, 24 April 2016

2016-04-24T03:52:41Z

← Older revision		Revision as of 03:52, 24 April 2016
Line 34:		Line 34:
	<syntaxhighlight lang="cpp">		<syntaxhighlight lang="cpp">
	#include "myo/myo.hpp"		#include "myo/myo.hpp"
			/*
	class MyDataCollector : public myo::DeviceListener		class MyDataCollector : public myo::DeviceListener
	{		{
Line 56:		Line 56:

	return 0;		return 0;
	}		}*/
	</syntaxhighlight>		</syntaxhighlight>

Mark: /* Basic Implementation */

2016-04-24T03:46:18Z

Basic Implementation

← Older revision		Revision as of 03:46, 24 April 2016
Line 32:		Line 32:
	To provide some context for the content herein, here's a minimal example usage of the Myo SDK.		To provide some context for the content herein, here's a minimal example usage of the Myo SDK.

	<~~pre~~>		<syntaxhighlight lang="cpp">
	#include "myo/myo.hpp"		#include "myo/myo.hpp"

Line 57:		Line 57:
	return 0;		return 0;
	}		}
	</~~pre~~>		</syntaxhighlight>

	In this example, we notice a couple of key concepts that guide further development in program control flow and Myo data acquisition.		In this example, we notice a couple of key concepts that guide further development in program control flow and Myo data acquisition.

Mark: added categories

2016-04-21T04:52:23Z

added categories

← Older revision		Revision as of 04:52, 21 April 2016
Line 11:		Line 11:
	Source: [https://github.com/mark-toma/MyoMex https://github.com/mark-toma/MyoMex]		Source: [https://github.com/mark-toma/MyoMex https://github.com/mark-toma/MyoMex]
	</ref>		</ref>
	~~Check out this [https://youtu.be/pPh306IgEDo video Preview on YouTube] to see a glimpse of what this package can do with acquiring data from Myo.~~

	Specifically, we'll address aspects of implementing the Myo SDK, the MEX wrapper for Myo SDK, and finally the Matlab class wrapper for the MEX file. Other information about using this Matlab package will not be documented here. Please refer to the files included with the package.		Specifically, we'll address aspects of implementing the Myo SDK, the MEX wrapper for Myo SDK, and finally the Matlab class wrapper for the MEX file. Other information about using this Matlab package will not be documented here. Please refer to the files included with the package.

			Check out this [https://youtu.be/pPh306IgEDo video Preview on YouTube] to see a glimpse of what this package can do with acquiring data from Myo.

	== Overview ==		== Overview ==
Line 193:		Line 194:

	</references>		</references>

			[[Category:Project]]
			[[Category:Academics]]

Mark: add link to youtube preview video

2016-04-21T04:48:00Z

add link to youtube preview video

← Older revision		Revision as of 04:48, 21 April 2016
Line 11:		Line 11:
	Source: [https://github.com/mark-toma/MyoMex https://github.com/mark-toma/MyoMex]		Source: [https://github.com/mark-toma/MyoMex https://github.com/mark-toma/MyoMex]
	</ref>		</ref>
			Check out this [https://youtu.be/pPh306IgEDo video Preview on YouTube] to see a glimpse of what this package can do with acquiring data from Myo.

	Specifically, we'll address aspects of implementing the Myo SDK, the MEX wrapper for Myo SDK, and finally the Matlab class wrapper for the MEX file. Other information about using this Matlab package will not be documented here. Please refer to the files included with the package.		Specifically, we'll address aspects of implementing the Myo SDK, the MEX wrapper for Myo SDK, and finally the Matlab class wrapper for the MEX file. Other information about using this Matlab package will not be documented here. Please refer to the files included with the package.

Mark: /* Myo SDK */

2016-04-16T05:48:37Z

Myo SDK

← Older revision		Revision as of 05:48, 16 April 2016
Line 36:		Line 36:
	{		{
	public:		public:
	void onConnect(Myo* myo, uint64_t timestamp, FirmwareVersion firmwareVersion)		void onConnect(myo::Myo* myo, uint64_t timestamp, FirmwareVersion firmwareVersion)
	{		{
	printf("onConnect\tMyo*=%20p\ttimestamp=%20ull\n",myo,timestamp);		printf("onConnect\tMyo*=%20p\ttimestamp=%20ull\n",myo,timestamp);
Line 70:		Line 70:

	<pre>		<pre>
	void onPair(Myo* myo, uint64_t timestamp, FirmwareVersion firmwareVersion) {}		void onPair(myo::Myo* myo, uint64_t timestamp, FirmwareVersion firmwareVersion) {}
	void onUnpair(Myo* myo, uint64_t timestamp) {}
	void onConnect(Myo* myo, uint64_t timestamp, FirmwareVersion firmwareVersion) {}		void onUnpair(myo::Myo* myo, uint64_t timestamp) {}
	void onDisconnect(Myo* myo, uint64_t timestamp) {}
	void onArmSync(Myo* myo, uint64_t timestamp, Arm arm, XDirection xDirection, float rotation, WarmupState warmupState) {}		void onConnect(myo::Myo* myo, uint64_t timestamp, FirmwareVersion firmwareVersion) {}
	void onArmUnsync(Myo* myo, uint64_t timestamp) {}
	void onUnlock(Myo* myo, uint64_t timestamp) {}		void onDisconnect(myo::Myo* myo, uint64_t timestamp) {}
	void onLock(Myo* myo, uint64_t timestamp) {}
	void onPose(Myo* myo, uint64_t timestamp, Pose pose) {}		void onArmSync(myo::Myo* myo, uint64_t timestamp, Arm arm, XDirection xDirection, float rotation, WarmupState warmupState) {}
	void onOrientationData(Myo* myo, uint64_t timestamp, const Quaternion<float>& rotation) {}
	void onAccelerometerData(Myo* myo, uint64_t timestamp, const Vector3<float>& accel) {}		void onArmUnsync(myo::Myo* myo, uint64_t timestamp) {}
	void onGyroscopeData(Myo* myo, uint64_t timestamp, const Vector3<float>& gyro) {}
	void onRssi(Myo* myo, uint64_t timestamp, int8_t rssi) {}		void onUnlock(myo::Myo* myo, uint64_t timestamp) {}

			void onLock(myo::Myo* myo, uint64_t timestamp) {}

			void onPose(myo::Myo* myo, uint64_t timestamp, Pose pose) {}

			void onOrientationData(myo::Myo* myo, uint64_t timestamp, const myo::Quaternion<float>& rotation) {}

			void onAccelerometerData(myo::Myo* myo, uint64_t timestamp, const myo::Vector3<float>& accel) {}

			void onGyroscopeData(myo::Myo* myo, uint64_t timestamp, const myo::Vector3<float>& gyro) {}

			void onRssi(myo::Myo* myo, uint64_t timestamp, int8_t rssi) {}

	void onBatteryLevelReceived(myo::Myo* myo, uint64_t timestamp, uint8_t level) {}		void onBatteryLevelReceived(myo::Myo* myo, uint64_t timestamp, uint8_t level) {}

	void onEmgData(myo::Myo* myo, uint64_t timestamp, const int8_t* emg) {}		void onEmgData(myo::Myo* myo, uint64_t timestamp, const int8_t* emg) {}

	void onWarmupCompleted(myo::Myo* myo, uint64_t timestamp, WarmupResult warmupResult) {}		void onWarmupCompleted(myo::Myo* myo, uint64_t timestamp, WarmupResult warmupResult) {}
	</pre>		</pre>
Line 132:		Line 147:
	Because of these phenomena, the validation of <code>emg</code> data involves determining whether or not the <code>emg</code> samples with a previous <code>timestamp</code> form a set with even cardinality. Since the <code>emg</code> sample time is significantly small (5ms), and the Bluetooth transmission of this data is not verified, it's very well possible that entire time instants (two <code>emg</code> samples) can be lost in transmission.		Because of these phenomena, the validation of <code>emg</code> data involves determining whether or not the <code>emg</code> samples with a previous <code>timestamp</code> form a set with even cardinality. Since the <code>emg</code> sample time is significantly small (5ms), and the Bluetooth transmission of this data is not verified, it's very well possible that entire time instants (two <code>emg</code> samples) can be lost in transmission.

	Within the limitations of the best-effort policy for streaming <code>emg</code> data in Myo SDK, the best we can do in acquiring this data is enforce a similar best-effort policy in validating the received data. When a new <code>timestamp</code> values is received, or if more than a pair of <code>emg</code> samples has been received for the same <code>timestamp</code> value, we validate the previous few <code>emg</code> samples. If an odd number of <code>emg</code> samples is found for the most recent <code>timestamp</code> then we pad this set with one extra sample to conform with the expected data format. Note that if data loss is undetected, it will be lost in pair of samples.		Within the limitations of the best-effort policy for streaming <code>emg</code> data in Myo SDK, the best we can do in acquiring this data is enforce a similar best-effort policy in validating the received data. When a new <code>timestamp</code> values is received, or if more than a pair of <code>emg</code> samples has been received for the same <code>timestamp</code> value, we validate the previous few <code>emg</code> samples. If an odd number of <code>emg</code> samples is found for the most recent <code>timestamp</code> then we pad this set with one extra sample to conform with the expected data format. Note that if data loss is undetected, it will be lost in pair of samples. Users should take much care in validating that data is not being lost throughout application development since there is no way to fully characterize lost data in the stream received from Myo SDK.

			=== Identifying Unique Myo Devices ===

			One may be interested in acquiring data from multiple Myo devices in the same session from Myo SDK. In this care, one can use the <code>myo::Myo*</code> pointer that is passed into the <code>myo::DevicesListener</code> callbacks to test for equivalence between a new Myo and a previously received Myo.

			A stripped down implementation of this technique may store the <code>myo::Myo*</code> pointers in a <code>std::vector</code> of, and rely on a single member function to performs both lookup of a new Myo from the vector and push back of a new Myo onto the vector. For example, consider the following.

			<pre>
			class MyDataCollector : public myo::DeviceListener
			{
			std::vector<myo::Myo*> myos;
			public:
			int getMyoID(myo::Myo* myo)
			{
			// return 1-indexed id of myo if it's in myos
			for (int id=0; id<myos.size(); ii++)
			if (myos[id]==myo)
			return (id+1);
			// otherwise, add myo to myos and return the id
			myos.push_back(myo);
			return myos.size();
			}
			};
			</pre>

	== Device Listener Class ==		== Device Listener Class ==

← Older revision		Revision as of 04:01, 24 April 2016
Line 73:		Line 73:
	<syntaxhighlight lang="c++" line>		<syntaxhighlight lang="c++" line>
	void onPair(myo::Myo* myo, uint64_t timestamp, FirmwareVersion firmwareVersion) {}		void onPair(myo::Myo* myo, uint64_t timestamp, FirmwareVersion firmwareVersion) {}

	void onUnpair(myo::Myo* myo, uint64_t timestamp) {}		void onUnpair(myo::Myo* myo, uint64_t timestamp) {}

	void onConnect(myo::Myo* myo, uint64_t timestamp, FirmwareVersion firmwareVersion) {}		void onConnect(myo::Myo* myo, uint64_t timestamp, FirmwareVersion firmwareVersion) {}

	void onDisconnect(myo::Myo* myo, uint64_t timestamp) {}		void onDisconnect(myo::Myo* myo, uint64_t timestamp) {}

	void onArmSync(myo::Myo* myo, uint64_t timestamp, Arm arm, XDirection xDirection, float rotation, WarmupState warmupState) {}		void onArmSync(myo::Myo* myo, uint64_t timestamp, Arm arm, XDirection xDirection, float rotation, WarmupState warmupState) {}

	void onArmUnsync(myo::Myo* myo, uint64_t timestamp) {}		void onArmUnsync(myo::Myo* myo, uint64_t timestamp) {}

	void onUnlock(myo::Myo* myo, uint64_t timestamp) {}		void onUnlock(myo::Myo* myo, uint64_t timestamp) {}

	void onLock(myo::Myo* myo, uint64_t timestamp) {}		void onLock(myo::Myo* myo, uint64_t timestamp) {}

	void onPose(myo::Myo* myo, uint64_t timestamp, Pose pose) {}		void onPose(myo::Myo* myo, uint64_t timestamp, Pose pose) {}

	void onOrientationData(myo::Myo* myo, uint64_t timestamp, const myo::Quaternion<float>& rotation) {}		void onOrientationData(myo::Myo* myo, uint64_t timestamp, const myo::Quaternion<float>& rotation) {}

	void onAccelerometerData(myo::Myo* myo, uint64_t timestamp, const myo::Vector3<float>& accel) {}		void onAccelerometerData(myo::Myo* myo, uint64_t timestamp, const myo::Vector3<float>& accel) {}

	void onGyroscopeData(myo::Myo* myo, uint64_t timestamp, const myo::Vector3<float>& gyro) {}		void onGyroscopeData(myo::Myo* myo, uint64_t timestamp, const myo::Vector3<float>& gyro) {}

	void onRssi(myo::Myo* myo, uint64_t timestamp, int8_t rssi) {}		void onRssi(myo::Myo* myo, uint64_t timestamp, int8_t rssi) {}

	void onBatteryLevelReceived(myo::Myo* myo, uint64_t timestamp, uint8_t level) {}		void onBatteryLevelReceived(myo::Myo* myo, uint64_t timestamp, uint8_t level) {}

	void onEmgData(myo::Myo* myo, uint64_t timestamp, const int8_t* emg) {}		void onEmgData(myo::Myo* myo, uint64_t timestamp, const int8_t* emg) {}

	void onWarmupCompleted(myo::Myo* myo, uint64_t timestamp, WarmupResult warmupResult) {}		void onWarmupCompleted(myo::Myo* myo, uint64_t timestamp, WarmupResult warmupResult) {}
	</syntaxhighlight>		</syntaxhighlight>
Line 116:		Line 101:
	The IMU on Myo measures raw gyroscope (<code>gyro</code>) and accelerometer (<code>accel</code>) data and uses these data sources to estimate the orientation of the device with respect to an inertial reference frame encoded in a unit quaternion (<code>quat</code>). These IMU data samples are provided by Myo SDK in the same time instant and are obtained through their respective <code>on<data>Data()</code> functions.		The IMU on Myo measures raw gyroscope (<code>gyro</code>) and accelerometer (<code>accel</code>) data and uses these data sources to estimate the orientation of the device with respect to an inertial reference frame encoded in a unit quaternion (<code>quat</code>). These IMU data samples are provided by Myo SDK in the same time instant and are obtained through their respective <code>on<data>Data()</code> functions.

	<~~code~~>void onOrientationData(Myo myo, uint64_t timestamp, const Quaternion<float>& rotation)</~~code~~>		<syntaxhighlight lang="c++" line inline>void onOrientationData(Myo myo, uint64_t timestamp, const Quaternion<float>& rotation) {}</syntaxhighlight>
	<~~code~~>void onGyroscopeData(Myo myo, uint64_t timestamp, const Vector3<float>& gyro) {}</~~code~~>		<syntaxhighlight lang="c++" line inline>void onGyroscopeData(Myo myo, uint64_t timestamp, const Vector3<float>& gyro) {}</syntaxhighlight>
	<~~code~~>void onAccelerometerData(Myo myo, uint64_t timestamp, const Vector3<float>& accel) {}</~~code~~>		<syntaxhighlight lang="c++" line inline>void onAccelerometerData(Myo myo, uint64_t timestamp, const Vector3<float>& accel) {}</syntaxhighlight>

	All IMU data is sampled on the Myo device at a rate of 50Hz (20ms sample time), and the <code>timestamp</code> values passed into the <code>on<data>Data()</code> functions are specified to be non-decreasing for successive samples. In practice, it's realized that successive <code>timestamp</code> values are typically strictly increasing (no duplicate sample times) so that identical <code>timestamp</code> values can be assumed to belong to the same sampling time instant.		All IMU data is sampled on the Myo device at a rate of 50Hz (20ms sample time), and the <code>timestamp</code> values passed into the <code>on<data>Data()</code> functions are specified to be non-decreasing for successive samples. In practice, it's realized that successive <code>timestamp</code> values are typically strictly increasing (no duplicate sample times) so that identical <code>timestamp</code> values can be assumed to belong to the same sampling time instant.