Hi Wondering if you have built another MEMs suit as I have technology that goes with these sensors allowing people to receive truly personalised instructional video for many applications.

really loved your project. just want to know if its complete yet?

Hi Álvaro, I'm checking your project and I find it awesome! I'm building something similar using BNO-055 sensors. I only have one question: Do you calibrate the sensors before using them everytime? I've been searching information about BNO-055 calibration and it doesn't seem to be very clear...

What cables are used to connect the sensors to the Microcontroller?

They are simply pieces of multipolar cable with crimped connectors to attach to the boards. I did that to be able to unplug them if needed, but that turned out to be a bad idea, since they kept disconnecting while I used the suit, so you can maybe consider soldering them directly. I'm thinking of going wireless for the next version, but it's going to take a while.

okay cool thanks, let us know how the effort to go wireless goes.

Do you have MotioSuit data I can use to run some tests with?

Wow sorry I took so long to answer, I just saw this. 

While I no longer have the suit with me, I did upload an FBX file to sketchfab (https://sketchfab.com/models/7f62f2baffbe4865a5dfb2e1b9b25d50#), but I'm afraid that's all I have until I get around to building the next version. 

Cool project!  What algorithm are you using for the sensor fusion?  Also, what sort of output speed do you get from the system?  On the video it looks like the animated character is running at (a very rough guess of) 10 FPS.  Is it the computer-side rendering which is the bottleneck, or reading all those sensors?

Thanks! 

The sensor fusion is running directly in each of the sensors, since the die includes a M0 processor that takes care of that as well. 

This makes the system go faster since all the sensor fusion runs on parallel and the main microcontroller only has to poll quaternion data from all the sensors and send it over bluetooth.

As for the speed, the bottleneck was definitely the screen-capturing software running in parallel on the computer. In the new video the system is running at 115200 bauds, which is the maximum I went, but the bluetooth module can go a lot faster (in theory up to 1382400, twelve times faster! ) so there is still some room for speed improvement :)

Cool, thanks for the info!  Looks like fun :-)

Question: as it contains a magnetic sensor, would it not be possible to have multiple electromagnetic reference 'anchors' that 'ping' in a cycle, to give absolute positioning for each IMU?  For example, electromagnet 'A' turns on for part of a cycle, then turns off while 'B', 'C', 'D', etc. turn on at their points in the cycle, with 'A' being twice as strong, to signal the start of the cycle.

Hi, just saw this. I haven't tried it, but I think that the magnetometer wouldn't give an absolute position, but rather the orientation in the ground plane (like a compass). I think this answer explains it quite well:

http://electronics.stackexchange.com/questions/36589/what-are-the-differences-between-a-gyroscope-accelerometer-and-magnetometer

Hi, cool work!

I have been thinking to build something similar myself. But can you tell me how bad the drift is in IMU only solutions like this? So if you stop moving and stand still for minute, does your virtual buddy here start drifting on some axis?

Can't say I know for certain, but 9 DOF includes magnetic sensors. They're the extra 3  dimensions, added to X, Y, Z, pitch, tilt, yaw. So you could get absolute position using those, assuming a consistent magnetic field. Either the Earth's, or perhaps it might help to put a magnet somewhere as 0. 

Dunno if the magnetic sense is as accurate as the inertial ones, probably not, but it does tie you to a fixed point in space.

Maybe Alvaro can correct me...

9 DOF IMUs do indeed include a magnetic sensor, along with an accelerometer and a gyroscope.

The DOF however would be accX, accY, accZ, gyroX, gyroY, gyroZ, magX, magY, magZ. To get orientation angles you would need to run a sensor fusion algorithm, which is in this case included in the chip's internal M0+ cortex processor.

With the magnetometer alone you would probably only be able to orient yourself on the ground plane, like with a compass but I haven't tested it :)

Thanks!

Well this is an ongoing project and is thus not finished yet. As of now, the version uploaded to github only replicates the user's movements but without moving around the space. 

In the sensor's library there is a function called 'Dead Reckoning' that needs some polishing but calculates position from acceleration.

If the acceleration is zero the velocity is either constant, or zero. Since walking at a constant speed is highly unlikely, we will assume it means that the user has stopped moving, and so we will set v=0. If we don't make this assumption, v would be equal to whatever value it had before, and so the position would change at a constant speed. Since we have decided to make v=0 when a=0, the position remains constant and there is no drift at all when the user is standing still.

There are however other things that need to be improved, like the actual function and its threshold values, and to be able to dynamically change the root of the armature from one foot to the other, depending on which one is on ground (like we do when walking) instead of having it be in the trunk as it is now.

Anyway, I've been working on this project for a few months now and I'm going to take a break from it for a while to work on other things, but if you finally decide to build your own and want to work on it I'll be more than happy to accept pull requests in github :)