.:: Previous Week ::: Next Week ::.
Week 4:
~ Monday, June 18 ~
I wanted to start this week on such positive note because it looks like I will be working with C++ a lot. This morning I tried fixing the problem with my code: whenever a user presses the A button the state of a variable controlling the recording should change (call it a switch). It sort of worked! The code would always see that the button was pressed; however, sometimes the program would remain in a paused state and sometimes it would resume the recording. I am not really sure why this happens...
I had to give the bluetooth stack to Takaaki, so that he can work on his code. Since I was planning on using only one wiimote I decided to connect it via the MSI dongle. A weird thing happened: my program would see that the wiimote is connected but it wouldn't communicate with it. To be specific, the LEDs would not light up but the message that it is connected would still appear. Takaaki (who I consulted about this issue) said that, perhaps, wiimotes use a specific chipset, and this dongle most likely doesn't have one. So, MSI bluetooth is of no use to us :(
I have been corresponding with Jimmy by email about the mocap files. The ones that I copied off of the mocap lab computer were in a different format than what he wanted to use. However, to convert it into the needed format we need to wait for the mocap lab people who are the only ones who can do it.
 |
| My partners in crime working hard |
 |
| My final product: two cute "ears" with LEDs and a USB plug |
No Star Trek tonight, because Jimmy, Takaaki and I went to the International Game Developer's Association meeting to build our own Wii 'Sensor' Bars. That's what I call a real hands-on experience :)
~ Tuesday, June 19 ~
Hep-hep-hurray! Today was a very good and productive day for me even though I was without Scramble (my desktop PC), which was taken away for a memory upgrade. First of all, I figured out exactly why I was having a problem with my code: because the loop, which checks whether or not the user pressed the A button is executed several times per second, by the time the button is released, the switch gets updated several times. Depending on how many times the program ran through the loop and changed the state of the switch during each pass, the switch sometimes would be on and sometimes it would end up being turned off. That put an end to me wondering why does "the program sometimes remain in a paused state and sometimes it would resume the recording."
Once I figured this out it didn't take too long before I was able to correctly map the "start" and the "pause" keys to the wiimote's buttons. Then, when I was testing my code I discovered another hidden trap in wiimote's communication with the PC. Remember how yesterday my program would see that the wiimote is connected but it wouldn't communicate with it? This is exactly what happened today but this time I noticed that even though the wiimote has lost its connection (I turned it off before I ran the program), it was still recognized by the computer, which made the program "think" that the wiimote is connected even though no data can be sent or received. Now I know that if this ever happens again I need to either check the wiimote's connection or remove the wiimote from the list of bluetooth devices and connect again.
Finally, I was notified that about half of our mo-cap files were converted into the proper .afs and .amc formats (the other half seemed to have some kind of problem that the mo-cap people will try to resolve in the next few days). Now we can test whether the wiimote data, which was recorded last week actually works.
Next, I tested the timer class for the application program and made it output elapsed time. At least now I know that it works!
~ Wednesday, June 20 ~
Meeting June 20, 2007 10:30 am
* Synchronization: use clap (or some other recognizable motion) to find correspondence between the mo-cap and the wiimote acceleration data and use it to synchronize them
* Re-record walking and running data with the wiimotes attached to the legs (instead of the feet)
* Record some upper body motion: leave all of the mo-cap markers on but use only two wiimotes
Types of motion may include: traffic controlling, yelling (fist waving) or narrating
* Compare the acceleration obtained from the mo-cap data (using differentiation) with the wiimote data and look for correspondence (use various filters to reduce noise?)
* Run a small test: pull out a segment of wiimote acceleration data and find similar patterns in the recorded data. Need to make sure that the motion found during this process fully corresponds to the ground truth data (if the initial segment included lifting up a foot from the ground, a similar acceleration pattern should also correspond to this movement)
Also,
Kate: read M. Dontcheva's paper on "Layered acting for character animation" and look for other papers that cited it (use Cite Seer or Google Scholar). Also, read M. van de Panne's papers and continue reading at a rate of at least a couple of papers a week.
Jimmy: reconstruct the experiment described in [one of Jessica's papers]. The goal is to follow [the setup described in the paper] as closely as possible.
Takaaki: the main priority is to work on balance maintenance. Using only one controller make the character react to the forces, i.e. if it is pushed from behind it should stick out the leg to maintain its balance or bend its legs before the jump to ''push'' itself off of the ground. Later, the experiment may be advanced to include the second controller but it's probably not going to be used to control legs
Next Meeting: Monday, July 2nd 10:30 am
~ Thursday, June 21 ~
I got the installation disk for Visual Studio 2005 and installed it in the mo-cap lab. The rest of the day I spent reading papers, which I found using CiteSeer:
* Style Translation for Human Motion by E. Hsu, K. Pulli and J. Popovic
* Predictive Feedback for Interactive Control of Physics-based Characters by J. Laszlo, M. Neff and K. Singh
~ Friday, June 22 ~
It is Aloha Friday! Yay!
The morning started off with a motion capture session. The session, with Justin as my test subject, went very smoothly. We even had fun during the capture: for one of the motions I asked Justin to pretend like he is narrating something, because I needed to record some typical conversation gestures. But why pretend when he can actually do that? We heard some funny stories about lifeguards and sharks, rain, cars and umbrellas :) Who said that research has to be boring?
The idea that you should either enjoy what you do or do what you enjoy was once again reinforced by a speaker, Doug Turnbull, who gave a talk on Music Search Engines today at CMU. In everything he said about his work one could hear strong passion, drive and enthusiasm. It is amazing how much he loves working on his project ! :)
The state of mind which enables a man to do work of this kind is akin to that of the religious worshiper or the lover; the daily effort comes from no deliberate intention or program, but straight from the heart.
~ Einstein
.:: Previous Week ::: Next Week ::.