New Code, New Sensors, New Data – Xan

The week started off with my rewriting all of the Arduino and sensor code for the MSK, after forgetting to save and losing the code that I did have. (Not such a big deal, as it was only 30 lines or so that needed to be rewritten.) I rewrote the code to have more features than the old code did, like the ability to write custom angles to the servo, and the ability to modify default values (e.g. Change what angle the servo gets set to if the sensor is triggered.) I also restructured the code to use methods instead of having everything running in the main loop. Ultimately, losing those thirty or so lines was probably a good thing. Of course, I expect that I’ll have to rewrite the code a few more times before the end of this project, whether it’s to allow for the control of multiple servos or to simply remove debug functions. 

Upon completing the new Arduino code, I also dug up some code for a utility called “Processing”. After a bit of rewriting, I was able to get the Processing code to work with my sensor. As seen in the picture, this new code allows for a real time graph of the muscle sensor data to be generated, something that is particularly useful in finding proper electrode placement.

Screen Shot 2015-02-13 at 12.20.18 PM

Of course, electrode placement is still a big problem, since I haven’t been able to get very consistent results thus far with the MSK. This is why I was very happy to receive a confirmed working EMG for experimentation from a teacher here at Westtown. With the new, (seemingly more sensitive) EMG, I’ve been able to get some great results in figuring out where to place electrodes. Perhaps more importantly, now that I have access to two EMGs, I can try sensing different muscles at the same time. If I can sense different muscles at the same time, I can control multiple servos, and the hand will be able to do more things – for example, the thumb could be controlled independently of the fingers. This new EMG differs from the one that I have currently in that it uses a different type of electrode and in that the output is not rectified. See below for an example (not mine) of an unrectified (top) vs a rectified (bottom) wave:

Unrectified vs Rectified

Note that the rectified wave has no dips below a certain point, while the unrectified wave does. This raw EMG output has been something that I’ve been interested to see.

By the end of the week, I want to have the Arduino and muscle sensor working to trigger the servo 100% of the time. After that, I can begin working on connecting the servo to the 3D printed hand, and a rudimentary prototype of the EMG control system can be tested. I’d also like to put the code that I have thus far on a GitHub repository. I’ll include a link to the repository after I create it.

4 thoughts on “New Code, New Sensors, New Data – Xan

  1. xanlorimer Post author

    I use the Muscle Sensor v3 by Advancer Technologies, and an Arduino Uno to process the data. – Sensor Board ($26.95) – Cable ($4.95) – Sensor pads ($7.95)

    Decent documentation for the Muscle Sensor v3 can be found on the first Sparkfun page linked above. Keep an eye on my Github page ( for this project if at some point you need code! (There isn’t any sensor code up there yet, but it will be coming soon!)

  2. aysha

    oh.thank you…btw i am working on my fyp which are using muscle sensor v3 too..but i try to drive the dc motor forward and reverse by using 2 kinds of it possible??may u give me some ideas please..

    1. xanlorimer Post author

      You could use a double threshold system, where you measure the output of the sensor to see if it passes one of two thresholds. The motor will activate to go forwards at one threshold, but will go backwards at a different threshold. They wouldn’t be different gestures per se, just different actions based on the force exerted by the muscle. This type of setup gets more complicated, because when you’re activating the higher threshold, you will inevitably pass the lower one. Care must be taken to ensure that the low threshold does not activate when the objective is to activate the higher one. Differentiating between the two can probably be accomplished through a clever averaging system: In pseudocode, we could say: if the average output of the sensor is greater than or equal to over , make the motor go forwards. If the average output of the sensor is greater than or equal to over , make the motor go backwards. Figuring out the time to average the sensor output, and the correct value of the threshold, will both require quite a bit of testing.

      Alternatively, you could try a system where, if the sensor activates once over a period of , the motor goes forwards. If the sensor activates twice over a period of , the motor goes backwards. This system requires less fine tuning, but may have higher wait times and be susceptible to accidental activation.

      The system that I’m going to use will combine multiple muscle sensors, along with some sort of averaging method to filter out accidental activations. I will eventually put some code up on Github with examples for both of the methods described above, along with my code for multiple sensors.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s