Use the power of your muscles to interact with the world

Similar projects worth following
Mumai is an open-source muscle-machine interface that connects your body to any kind of electronic or mechanic device through the myoelectric (EMG) signals generated by your muscles.

The uses of this interface are limited only by your imagination. It can be used to control assistive robotic devices such as prostheses or exoskeletons. Alongside some of the freely available machine learning libraries (Scikit-learn, TensorFlow, Dlib...) it can be used to implement a gesture recognition controller to interact with electronic devices such as computers or smartphones. In the sports field, it can be used to optimize the level of exercising. At a university level, it can be used in biosignal processing courses, working as a biomedical instrumentation device. How this device will be used depends on you.

The problem

Electromyography, or EMG, is a technique from the medical field that comprises the recording and the study of the electric signals generated when a muscle contracts. EMG is widely used in clinical applications: kinesiological studies, medical diagnosis or rehabilitation, among others. Also, EMG is the preferred method to control robotic prosthesis or exoskeletons, since using the user's cognitive processes is a natural and intuitive way of interacting with such devices. Besides these applications, EMG can also be used in hands-free computer control, physical training optimization, interactive art...

Professional EMG systems are very expensive, cumbersome (with lots of cables connecting the electrodes to the amplifier) and complex, and for this reason their use is usually limited to hospitals or professional laboratories. Although there are some portable and simpler professional EMG systems, they are also quite expensive to be used by hobbyists or research labs with a moderate budget.

The solution

The aim of this project is to develop an affordable and open-source wearable wireless network of EMG sensors that can be placed on any muscle. With this project my intention is to develop a hacker-friendly biofeedback interface to control devices ranging from computers or smartphones to robots with EMG signals. It can also be used simply as an instrumentation system to view and analyze the acquired EMG data. Although it probably cannot be compared with professional systems in the market, the EMG signal acquisition circuit is carefully designed, using low-noise components and techniques for active suppression of mains hum. Wireless communication allows the use of multiple sensors without the large number of cables that this type of devices usually have. Also, the wireless architecture allows for a great flexibility since there is no fixed number of acquisition channels.

Each EMG sensor is connected to a ESP8266 module, forming a Mumai node. The nodes send the EMG data through WiFi to a computer, smartphone or other devices, such as a robot or a home automation system. The following diagram summarizes how this interface works.

There are three ways this interface works, depending on which device the nodes connect to:

  1. Computer interface: Mumai nodes connect to the local WiFi network to which the computer is connected.
  2. Smartphone interface: Mumai nodes connect to a WiFi access point created by the smartphone.
  3. Device interface: Mumai nodes connect to a WiFi access point created by an extra node connected (through UART, SPI, I2C...) to the device to be controlled.

In all three modes, the controlled device retrieves the EMG data of each node accessing to its corresponding IP address. In each case, some kind of software is in charge of this (e.g. a Python script in the first case, an Android app in the second case or an Arduino program in the third case).

It should be clear that Mumai is just an interface to transmit EMG data from any muscle to a variety of devices, it is a bridge between your body and the device you want to control. How the data provided by this system are used is up to you. I will post some use cases on the project logs, as well as on the Github repository, that may serve as examples of how Mumai can be used.


  • Raw EMG signal output.
  • Low-noise, high quality signal.
  • Easy to setup and use.
  • Compact and comfortable to wear.
  • Fully open-source.

Use cases

  1. EMG gesture classifier
  2. Bruxism alarm


This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

The EMG sensor used in this project is based on my MSc thesis, where more information regarding the design and operation of the circuit can be found.


PCB file (Eagle) of the EMG circuit

x-kicad-pcbnew - 116.87 kB - 04/23/2016 at 19:18



Schematic (Eagle) of the EMG circuit

x-kicad-schematic - 211.31 kB - 04/23/2016 at 19:18



Arduino code for a NodeMCU board to test the external ADC and the wireless data transmission (under development)

x-c - 4.18 kB - 05/30/2016 at 14:13


  • Citizen Scientist application: bruxism alarm using EMG

    Alvaro Villoslada07/10/2016 at 15:57 0 comments

    Bruxism is a condition in which those who suffer from it inadvertently clench or grind their teeth with excessive force. This can happen during the day (awake bruxism) or while sleeping (sleep bruxism). Depending on the frequency and severity of bruxism, it can cause jaw disorders, headaches or tooth wear.

    A way to stop severe bruxism from causing health problems is by automatically detecting the periods of clenching/grinding and alerting the bruxer in the case of awake bruxism, or waking him up in the case of sleep bruxism. As bruxism is caused by an unconscious contraction of the temporalis and masseter muscles, an episode could be detected by measuring the EMG signals generated by one of those muscles. The detection of an abnormally large EMG signal could trigger some kind of alarm, such as a beeping sound or a vibration, in order to alert or to wake up the bruxer.

    With all the above in mind, I have developed a simple prototype of a bruxism alarm using one Mumai EMG circuit, as an example of what can be done with this myoelectric interface. The video below shows the elements that compose the prototype and how it works.

    The operation of this system is very simple. The measuring electrodes are located over the masseter muscle and the reference electrode is placed over the bony area behind the ear. After turning on the system, it has to be calibrated. First, the EMG signal baseline is measured by having the masseter muscle at rest during 30 s. This value is subtracted from all the measurements taken from this moment, to have a baseline of 0 V. This step needs to be performed in order to calculate the running moving average of the measured EMG signal. The running moving average is used to process the raw EMG signal provided by the Mumai EMG circuit by computing its amplitude.

    During the second calibration step, the user performs a strong contraction with the masseter muscle by strongly clenching his teeth. This gives a measure of the maximum force the user is able to exert, which is known as maximum voluntary contraction (MVC). The activation threshold (the value which will trigger the bruxism alarm) is computed as a percentage of the MVC.

    After calibration, the system enters into operation mode during which an audible alarm, provided by a buzzer, is triggered every time the amplitude of the EMG signal exceeds the activation threshold. This mode could be improved by activating the alarm only when the amplitude of the EMG signal exceeds the activation threshold during a predefined period of time. In this way, false positives would be avoided and the system would be more robust.

    The code I have used to implement the bruxism alarm is hosted on the Mumai repository.

  • Citizen Scientist application example: hand gesture classifier

    Alvaro Villoslada07/07/2016 at 17:23 0 comments

    One of the most common applications of EMG signals in the research field is to use them as inputs of machine learning algorithms to classify gestures performed with the hand. These classifiers are very useful to control robotic hand prostheses with more complex controllers than the usual threshold-based on-off controllers. But they also have an application in the recreational field: they can be used as part of a hands-free control system for computers, video games or mobile phones.

    As a tutorial/application example of how such controllers can be implemented, and as part of the Citizen Scientist challenge, I created a Jupyter Notebook with a step by step explanation covering the different aspects about one possible implementation that relies on Python and its scikit-learn library.

    Implementation of an EMG-based hand gesture classifier

  • To WiFi or not to WiFi

    Alvaro Villoslada05/29/2016 at 13:14 0 comments

    After putting together the EMG circuit that I have designed for this project, a 24-bit ADC to digitize the analog measurements of the circuit and a NodeMCU (ESP8266-based board) to get the digitized signals and to send them wirelessly to my computer, the first prototype of a Mumai node was ready for testing.

    One of the most critical aspects of the system nodes is their data transmission rate. The EMG signal has a bandwidth of 20 to 500 Hz, which implies that, in order to digitize it with no aliasing, it has to be sampled at least at 1 KHz. If each reading is sent to the receiving device once sampled, that means that the nodes have to read from the external ADC and send the measured data point every millisecond. With WiFi, this shouldn't be a problem since this technology allows high transmission data rates.

    I wrote a very simple Arduino program for my ESP module, using the fantastic ESP8266 core for Arduino, to see how long it took the module to send individual measurements to my computer. The results I obtained weren't very encouraging: using the client.println command to send a floating point number took a mean time of about 26 ms, way too high for the system requirements. From my own experience, I know that sending data from an Arduino to a computer through the serial port with the Serial.println command consumes more computing time than doing it in byte format with the Serial.write command. So I thought that maybe this is also the case with the wireless communication commands, and I tried sending the data in byte format with the client.write command. After converting each measured floating point number to a four byte array (to do this, the union data type is extremely useful), and sending them to the PC, the mean computing time was reduced to about 5 ms. The improvement was remarkable, but it was still above the required time. And that's when I started thinking that maybe WiFi was not the best option as I thought.

    Of course, sending each data point individually is, like we say in Spanish, "killing flies with cannon fire" (I have searched the English equivalent and it is "use a sledgehammer to crack a nut"). So I modified the basic testing code to send a data buffer with 100 data points in byte format. And it turned out that sending a 400 element array with the client.write command took the same time than sending just four bytes: 5 ms. A hundred data points means a 100 ms data segment of the EMG signal, so a 5 ms interval to send these data chunks seems more than acceptable. Problem solved.

    But the seed of doubt was already planted. When doing all these tests, the sending time varied, sometimes a lot, between readings. That makes sense since the WiFi transmission rate depends on a number of factors: usage of the network, hardware (the router, the computer WiFi card), WiFi coverage... This made me think that, if I need a stable data transmission rate, perhaps WiFi is not the best option to implement the wireless network. Besides that, there is the problem of energy consumption. The EMG nodes need to transmit data continuously; this is not a IoT project where a sensor needs to send information once in a while. And WiFi is a more power hungry technology than other options. I still have to measure power consumption but, if this system is to be used for maybe hours, autonomy will be an important factor to consider.

    I will explore other wireless alternatives to see what are my options. One of these alternatives is ZigBee with XBee modules but, although ZigBee is great for implementing mesh networks, XBee modules are quite expensive. My other preferred candidate is the NRF24L01+ module. This little device has a baud rate of 2 Mbps (when I did some tests back in the day, it took about 800 us to send individual data points), a power consumption of 11.3 mA during transmission and 13.5 mA during reception (according to the datasheet), a great Arduino library to program it, and they can be found at a very low price. The downside of using either...

    Read more »

  • Selecting the proper wireless technology

    Alvaro Villoslada05/27/2016 at 10:26 0 comments

    Why have I chosen the ESP8266 as the wireless module for this project? There are plenty of options to go wireless, as this complete Hackaday article illustrates. Since I want the EMG circuit to be able to connect to a range of devices as wide as possible without using additional hardware, I need a wireless technology that is present in most everyday devices, such as computers and smartphones. This leaves me with basically two choices: Bluetooth and WiFi. Because of how I envisioned the network topology, where there are several EMG nodes that send the measured signals to a central node which receives and process the incoming data, I need a technology that at least supports a star network topology. However, it would be desirable to be able to use a mesh topology, to improve the robustness of the network in case of failures.

    A star network can be implemented with Bluetooth, but the master can only connect to a maximum of seven slaves, which limits the number of EMG nodes that could be used in the interface. It seems that BLE allows a large number of slave nodes, and support for mesh networks is being developed, but currently BLE modules are not as affordable nor there are as many developed libraries to program them as with other wireless modules.

    For these reasons I thought that WiFi, and the ESP8266 module, was the technology that fitted my needs. With WiFi, a star network can be implemented, with all the EMG nodes connected to a single access point (either a router, a smartphone or a special node). There is even an Arduino library to implement mesh networks with the ESP8266 modules. The ESP8266 is well known for its low price, as well as for the possibility to use it as a standalone microcontroller, so it seemed that I had found the missing piece to start developing the wireless part of the EMG interface.

    But (there is always a but) after some time doing tests with this module, and after much thinking on what are the pros and cons of its choice, I am not so convinced that implementing a WiFi network of sensors is the best option for this particular project. For the sake of brevity, I will explain the problems I've encountered and what options do I have to solve them in the next project log.

  • Boosting the analog input range of the ESP8266

    Alvaro Villoslada05/17/2016 at 11:15 0 comments

    When I started testing the EMG circuit of Mumai, I used a regular Arduino to digitize the analog signal that the circuit outputs. The Arduino ADC has a 10 bit resolution and a default input range of 5 V (if not using an external analog reference). That is enough since the maximum output range of the EMG circuit goes from 0 to 5 V, with the signal centered at 2.5 V.

    However, when I began the integration of the EMG circuit with the ESP8266 to start working on the Mumai nodes, I stumbled upon one little problem: the maximum amplitude that the ESP8266 ADC can measure is only 1 V and there is no external analog reference to have a greater measurement range. So, with a signal centered at 2.5 V, this limited input range meant that EMG data would be completely unusable.

    Fortunately, I had one external ADC from some other project lying around: a LTC2440, with an amazing 24 bit resolution, external analog reference and SPI communication. With just the power connections, three wires for the SPI an a small piece of code to retrieve the data from the bus, the first prototype of a Mumai node was up and running.

  • We have EMG (on the curse of electronics)

    Alvaro Villoslada03/21/2016 at 19:02 0 comments

    Everyone who has ever designed an electronic circuit knows the anxiety of the first power up of a new prototype. Maybe it's just me, but rarely a newly designed circuit works as expected the first time electrons start flowing through resistors, capacitors and ICs. Thankfully, we have breadboards and perfboards to build and test a prototype before jumping to a PCB design. But even so, after spending hours soldering your new and shiny PCB, having inhaled the fumes of solder, with back pain and eyestrain, because of some kind of mysterious black magic, you power up the circuit, measure its output and... nothing happens. So it begins the process of "debugging" the circuit: checking and rechecking the schematics and PCB design, testing continuity, measuring the output of every stage... If you are lucky, the problem is due to a faulty IC, or for placing the wrong component. But sometimes the problem is worse, and you have made a design mistake in the connection of some components, or the traces are not wide enough to withstand the current flowing through them, or the grounding is badly designed and induces lots of noise on the system, or you forgot to put that 10 pF capacitor in pin 13 of U4 that didn't seem that important...

    Of course, the first test of the EMG sensor was no exempt of the "no signal at the output" problem. Thankfully, the problem was solvable, two components were misplaced and the values of two resistors were wrong. So after desoldering and resoldering the problematic components, I powered the circuit again, measured the output and... hurray!!! A nice and clean EMG signal popped out on the oscilloscope screen. The project goes on.

View all 6 project logs

Enjoy this project?



Bodo Hoenen wrote 11/23/2016 at 01:31 point

Wow, I'd love to learn more. My daughter and I have been working on an assistive robotic arm since her arm was paralyzed a few months ago. We are now trying to find a way to create open source myoelectric signal recognition software. We have been using proprietary software but will not be able to afford to licence it, especially as we are also trying to help the thousands of other children like my daughter too. You can read our story here:

Is there a way we can get in touch, share resources, skills, advice? I also have the project here on hackaday:

  Are you sure? yes | no

Dimitris Zervas wrote 07/24/2016 at 06:21 point

Wow, amazing. Seems that you're in a pretty good stage (not alpha...)! What's the final BOM and how much would/do you sell one of these?

  Are you sure? yes | no

Grayson Schlichting wrote 04/24/2016 at 06:28 point

Outstanding!  And congrats on your pain-free "first spark" testing - the video looks VERY promising!  -Grayson

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates