Mark Wilson's Blog

Biorobots: Exposition

Midterm exam tomorrow in Computer Graphics (EECS 366) -- actually, today now, since it's past 1 am. I've covered as much of the material as I could in the time I had available and it doesn't feel like enough, but I'm not sure how much more I can do for myself before the exam and I need a break anyway, so I'll blog instead.

I thought I'd ramble, as briefly as possible, about my work for a new course the university's offering this semester, EMAE/BIOL 377. Eight undergraduate students participate in a semester-long research project on biorobotics.

To explain my presence in the limited enrollment: The course was originally designed to include four biology students and four mechanical engineers, but they only ended up with three mech/aero engineers. What with one thing and another, I ended up sitting in on a class session and talking with the professors about what I might be able to contribute.

In light of my interest in artificial intelligence, my real interest in biorobotics would tend to run more toward some research the university is doing in the neural structure of the cockroach (many of Case's biologically-inspired robots are drawn at least partially on the model of the roach). However, that's more than a little outside the scope of the course, and the students as a group ended up deciding that an interesting project for the semester would be researching feet and attachment devices -- Robot V, Case's latest roach-bot, has problems with its feet slipping out from under it, and if we're lucky we may find something of use for the Whegs robots as well.

Accordingly, it was suggested that a role I might fill nicely was that of designing a computerized simulation of the roach's foot. Graphical simulations were done of the roach for earlier robots, but like the engineering and the biology research these basically ignored the foot.

I've never done a graphical simulation of anything before, so this is uncharted territory for me; however, last semester I delved a bit into graphics programming as part of my interest in game programming. I am, therefore, not totally lost in the woods -- just wandering around in the dark with a GPS device that's constantly fritzing out.

For most of the semester so far I've been either waiting on preliminary data from the biologists or doing other stuff, but the design of the simulation is finally starting to take shape. I knew I'd be programming in C++ and OpenGL from the start, and I've got some basic structures set up to model the feet which will translate easily into wireframe display. The current problem to solve is how exactly to animate the thing.

I'm lazy and don't want to have to specify three skillion frames for each foot. Besides that, I want to incorporate a playback-speed control so that viewers can see the thing at full skitter or at a speed more conducive to close observation, and the slower I go the more frames I have to write in order to avoid a case of the herky-jerkies. Some blend of keyframing and inverse kinematics, then, seems like the way to go -- the computer can figure out as many frames between A and B as it needs. The problem with that approach is that it's not nearly as easy to program as frame-based playback, and I've never programmed IK before. I have a basic idea how to do it, but it still scares the bejeebers out of me.

At any rate, I'm nearly done setting up the data structures to hold the animation data -- a circular linked list of the keyframes that I want the foot to visit, essentially, so we can repeat the animation over and over and over again. (Hmm. I just remembered something Nicole suggested when I was talking about IK's heavy computational requirements in comparison to forward kinematics -- precompute the in-between frames according to playback speed and store them in a data structure of their own. Something that should have occurred to me in the first place while I was thinking out this design. Time to write some more supporting structures.)

After I get all the underlying objects ready, I think it'll be an incremental build to the IK animation -- just hop from waypoint to waypoint first, then perhaps some partial rough animation between them, and then just keep going from there.

Well, this has gone on much longer than I meant it to, but now I have my basic approach out of my head and down in a more concrete form, so maybe I can free up that brain space to think about how to improve this. Or, better yet for the moment, to think about that graphics midterm.