Serializer WL or other method for hardware dummy?

[nate]

Hello everyone!

I'm new to the concept of tinkering with hardware, but I have some projects I need to help knockout for some joint venture ideas with a friend.

The first project is to take input from a set of flexible stretch sensors (like the ones found here : http://www.imagesco.com/sensors/stretch-sensor.html ), and get that data back to the computer (by wireless means if at all possible, bluetooth or wifi).

Second project is to transmit that data and the positioning of some sensors on a small 1.5-2 foot skeleton.  Like the above, this information will be sent to the computer wirelessly as well.   I'm wanting to know the position of joints and possibly a gyro. Once there, I'm going to be developing some software that allows you to assign the movements in real-time to 3D animation cartoon sequences (pretty fun eh?). 

Ultimately, this "toy" would allow folks to create avatars and put together little stop-motion pictures without so much stopping.  Additionally, I'm writing some software with basic phonetic decoding to lip sync audio onto the chars.  This would result (hopefully) in allowing rapid prototyping and animation of mini-cartoons. 

The good news is that I'm very experienced as far as software and have been in the field professionally for well over a decade.  I can handle doing just about anything with the data, once I get it.  Which brings me to the problem of getting that data!

I'm looking at the Serializer WL controller as a foundation (http://www.roboticsconnection.com/p-16-serializer-net-robot-controller.aspx) - mainly because it appears it has some level of built-in hardware support for the wireless capabilities and a number of analog and digital sensor inputs.  It looks to be somewhat a turnkey solution (with supporting documentation that I'm comfortable with for developing event listeners and handlers).

My questions are:

1) Has anyone worked with Serializer WL, or another serializer that can take variable sensor inputs and get them into a robust and high-level development library like .NET?

2) Does anyone know if something like the Serializer WL could work with the flexible stretch sensors?  Obviously it would need some other type of component to attach to the serializer, and I haven't got a clue as to what.

I am more than willing to help fund someone's beer supply via paypal for some helpful insight to get things kicked off via paypal because my lack of hardware understanding is annoying.  I'm also happy to soak up any ground level tutorial stuff anyone can point me to.  I've spent my free time in the past week trying to find some but coming up somewhat empty handed (just finding an active community like this was harder than I expected - my posts at some other sites got 2 reads in one week!).

If someone could help me get some of this sensor data into .NET via the WL or similar methods, I would be willing to purchase you a duplicate set of the components to help show me the way (for you to keep for your own projects in the future!).

Thank you for reading this long winded post and I appreciate any insight you can give me!

-Nate

[nate]

To clarify, I don't need to send any data back to the bot / serializer.

Basically, I just need this to take the input data and send it over so there is no need for any servos of anything.  This will basically be just a dummy input device to send me the movements like a somewhat sophisticated analog controller or keyboard etc. 

I'll then store them (in a database or stack) and apply them to the 3d model skeletons for playback, clipping and editing.

Can anyone point me to a good starting place to tinker with?

Thanks again for looking!

[Soeren]

Hi,

My first thought was that this serializer is a waste of output units (for your purpose) and you'd be better off with an input only device (bought or constructed).

But first things first.
You need to decide how many sensor inputs you need all in all and how detailed you need the dummy to be (the human body has got quite a bit of joints of diverse nature, an elbow eg. can both go "up and down" and "rotate" side to side, less than 90°, so it's two sensors just for an elbow).

Then you need to decide the resolution needed in each sensor - either 8, 10 or 12 bit systems might be realistic I guess.
Finally, the speed of reading all sensors might be important.
Before this is planned, there is no need to look for hardware, as this will specify the minimum demands to the hardware.


A separate fullsize head would probably be best, as a foot long dummy would be hard to make any mimicry in by hand.
Did you by the way consider the method used for SFX on most movies nowadays, where a camera tracks single white or reflective dots on joints on a black full body suit filed against a background of matte black?
Much easier than moving a dummy, just suit up and do the moves, which can then be mapped to a 3D avatar, either in real time, or as a batch job (depending on needs and processing power).

[nate]

Hello Soeren - thank you for your reply!

I am familiar with what they do for motion capture in today's films - which results in very accurate motion on many, points (not just joints).  That process however is reasonably complex, requires very expensive equipment and a fair amount of technical knowledge and expertise to accomplish.

What I'm after is actually something intended to be easily understood and attainable by kids pre-teen-ish and up.  This "toy" would allow kids to interact with miniature 1-2 foot models much the same way they do with other toys, only it could motion capture those movements and because we know what sensor moved where, there wouldn't be any configuring or lining up this joint with this bone in the model.  All of those relationships would be pre-defined in the software - so it hopefully will be similar to - push this record button (in software), move the doll in a mini sequence, hit stop - then hit play to see it applied to different cell-shaded 3d characters, or more likely, a vector based representation in flash (web enabled).

I know it will be very rough, and not highly accurate, but again, we're talking about an intended audience of kids or cartoonish-level sophistication.  I would in fact be happy if a knee joint had one of 5 or 6 positions, it wouldn't *have* to have a really high level of detail (but if possible, great!).  So with that being said, I imagine an 8 bit system would be sufficient.

If I can just get my hands on the information - I'm golden, I have the software expertise, I just need some help figuring out the hardware wizardry - and am happy to purchase, tinker, play and break my way to a prototype with any help I can find.

As far as the number of sensors:

Must haves: Shoulder - 2, Elbow- 1, Leg or pelvic-2 sensors (for kicking sideways and forward), knee-1
Like to have: Neck 1 sensor (horizontal rotation), feet & writs, 1 sensor.

So that puts the sensor count around 12 for minimalistic, 17-20 for ultra nice.

Lastly, I'd like to add a gyroscope -and possibly an accelerometer (so I can tell the different between the bad guy standing up straight or lying down dead!)

I'd like to poll it as much as possible, I can certainly handle the data - but I would imagine 15-30 times a second would be ideal, but every 200ms or 5-6 times a second would probably be sufficient.

Thank you for your reply thus far I appreciate the input greatly!

-Nate   

[Soeren]

Hi,

it could be made with 4 bit sensors then. That would make it cheaper and faster (since less data should be transferred.
Sensors could be optical (Infrared reading a patterned disk) and they could all be rotational sensors I guess.

That leaves the gyro/accel metering, which could be with digital outputs, so no A/D-C would be needed.
Do you need a triple gyro/accel or...?

It could be transferred via eg. Bluetooth from a controller just gathering the inputs. However, it's 80 lines + gyro/accel

How do you plan to construct the "doll"?

[nate]

Sensors could be optical (Infrared reading a patterned disk) and they could all be rotational sensors I guess.

I'm open to any ideas for the rotational sensors, although, I was under the impression the infared stuff would be somewhat fragile - but this is just a concept and we could use some sort of casing or change it after the initial prof of concept.
 

Do you need a triple gyro/accel or...?

Trippe would be ideal for the gyro - dual for the accelerometer (or we might kill the accel) - the gyro would be a must have though.

How do you plan to construct the "doll"?

For the first pass, anything will work - we can build it out of pvc or legos or old fashioned erector sets.  I don't want the design of the system to be heavily influenced by the toy construction, but the other way around.  Ideally the toy would eventually just be a rudimentary skeleton that we would eventually wrap with something else or put into something else (even a stuffed toy or something).

Thanks again for the input!   

[nate]

What would be the best controller if I only want to receive data, not send any back? 

[Soeren]

Hi,

The best would IMO be, to select a microcontroller with enough I/O-lines (and enough A/D-C lines if analog output gyro/accel is chosen) and then build and program it to either gather data and send them continually, or to wait for a poll and then read all sensors once and report or whatever would be your strategy.

I'll have to let you hang a bit with a more elaborate answer (to your previous post as well), since I have less than 3½ hours to sleep and then I'm off to the airport going to Warsaw (work related) for a quite focused time from morning to bed time, so I won't be able to do anything robot related until I'm back home Monday.