In a not-so-distant future we will be surrounded by robots. How do would a human interact with them and tell them what to do? There're many ways, for example by using visual clues or speech commands. However, a more exciting and effective way is to send commands to a robot directly from a human brain.
We used muscle activity as a proxy for brain impulses. When you flex a muscle, there's a potential field created in the area near to the muscle. We measured that potential field, processed the signal, classified 4 different types of action and used them to remotely steer a spider robot.
As a result, depending on how an operator moves their hand, the robot will either move forward, turn or stay still. The signal processing algorithm generalizes well between different people after a quick automated calibration.
We're really prod of the result, because at the beginning of the project it wasn't clear at all whether the whole thing worked out. At the end it works quite reliably and you can actually use your hand as a controller for the robot. Come talk to us to see it yourself!
Along the way we learned a bunch of things:
- Electrode placement is extremely important. If placed incorrectly, you can't separate cleanly between different hand gestures
- There can be interference from the wires themselves, a simple hack is to twist them.
- Try the simplest possible algorithm first, we managed to classify signals by simple moving average and double-thresholding.
- Bugs are usually also simple. Don't do any assumption about which part of your system is working reliably, make hypotheses and try to verify them in order of simplicity.
- Bluetooth is unrealiable, electrodes can dry out, batteries discharge. Therefore having test that can verify that a single part of your system is working is very important. E.g. controlling robot without EMG, visualizing EMG without the robot etc.
- No premature optimisation. Write unoptimized code, see if there're bottlenecks, optimize those
- Robot control is hard.
- A system is as weak as its weakest link. Identify those and try to make them more robust. E.g. in our case, one EMG sensor was better than the other, the signal from one muscle was stronger than the other. We combined better sensor with weaker muscle.
- Hardware projects are hard, especially during the hackathon. You can download a missing library, switch to another one if you discovered a bug. Whereas malfunctioning hardware is a show-stopper. Invest time upfront to make sure you hardware setup is as good as possible and then hope for the best.