Entries in "Biorobots"
Graphically presenting Boolean expressions?
KDE's UI libraries take some more getting used to than GTK, but once you've got the hang of them it rapidly becomes apparent that they form a much more powerful system, both in terms of features and in terms of structures. (This is, I suspect, particularly true for those of us who are native C++ speakers.)
The plotting widget is finally, I'm happy to report, working. Now the immediate challenge is to get the UI design right as the engine that drives the robot coalesces.
The UI has three primary functions: One is to record and display data which are coming back off the robot as it runs, one is to allow biologists to easily alter certain settings to see how that changes the robot's motion, and one is a placeholder because I probably forgot a function. The second function is the one I'm currently interested in -- it is necessary to change certain conditions which, when met, trigger a behavior pattern in the robotic leg.
The problem is that these conditions may be somewhat more complex than a simple "alpha > 25" -- they can actually be full Boolean expressions of the form "(x = true AND alpha > 25) OR beta < 16". It's unlikely that they would ever grow overly complex, but the uncertain morphology of the expressions presents a certain problem in terms of interface, if I end up being required to present the and/or relationships between clauses.
The simple and obvious solution is to present the user with a textbox and allow him or her to enter a Boolean expression. However, this introduces every programmer's nightmare -- verification of user input -- and means we could end up with Boolean expressions of arbitrary length, which the engine authors would like to avoid.
The next solution that occurs to me, being a computer scientist, is to present the expression as a tree. Computer scientists like to represent things as trees. Mathematical and Boolean expressions can be represented thusly:
-Operator | -----Operand -----Operand
And, of course, an operand can be a subtree of its own, consisting of another expression. This could be presented in a tree-view widget, similar to the displays used for the directory structure on your hard drive. There are many advantages to be had here: Clean presentation, simple navigation, and even the ability to let the user add and delete clauses from the expression within constraints of my choice.
The problem, of course, is that while computer scientists like trees, I think it's fairly unlikely that biologists are terribly familiar or comfortable with this representation of such expressions. Which leaves me looking for another way to represent Boolean expressions in a graphical UI. Suggestions welcome, particularly if they involve standard widgets.
SOURCE
On Thursday, April 14, the SOURCE Symposium and Poster Session will be held from noon to 4 pm in the Thwing building.
Both EMAE/BIOL 377 teams (biology and engineering) will be showcasing posters and, presumably, caffeine-fueled, sleep-deprived undergraduates who will be happy to talk to you about the project and the cool things cockroaches can do, or to accept your donation of a mallet to the head. If you're interested in biorobotics, or if you think somebody else might have a research topic that could be interesting, stop by.
I am now qualified to write screensavers.
Because there's a biorobotics meeting tomorrow (today, whatever) and it's nice to have some illustration that you have in fact done work since the last meeting, I hacked together a simple demo of the Bézier-spline interpolation for keyframe animation this evening.
(Incidentally, if anyone reading this thinks I'm using perfectly good kilobytes to record trivial details, that person is probably right. However, I have to document all my work at the end of the semester and this will serve nicely as a record to which I can later refer, in addition to allowing me to talk out my plans for the program and others to read them should they be struck by brain fever or something.)
Anyhoo... Bézier interpolation. Screensavers. Forward!
Continue reading "I am now qualified to write screensavers."
Animation progression
So, since luckily this is a fairly light week for me, I'm getting some work done on this whole animating-the-cockroach-feet bit. Programming is fun but time-consuming.
Of course, the problem I'm working on right now is smooth, realistic keyframed animation. I was worried it would involve programming all kinds of ugly calculus for the interpolation, but a conversation with the president of our student chapter of the ACM, who knows something about practically any type of programming you care to mention, quickly dispelled that fear. You do it with Bézier curves, which are essentially (this is my inexpert take on it) weighted sums of localized polynomials over a set of control points.
If that made no sense, don't worry. I couldn't for the life of me do anything in-depth with the math or tell you why it works, but it's reasonably easy to apply once you know the algorithm. The upshot is that you get pretty curves, as follows.
Continue reading "Animation progression"
Biorobots, more and more
Attended an ACM event tonight on animation. Not a lot of what was said was in any way directly applicable to what I'm doing for EMAE/BIOL 377, since the talk centered around Maya (a pre-authored, high-powered, but ungodly expensive animation tool), but it was a good event in that it got me thinking about some issues I'm going to have to deal with in using keyframed animation.
It's good to think about issues now, because I finally got around to reading in keyframes and hopping from one to the next in the program this past weekend, and most of these issues are the next big step. I don't want to get up to my neck in code and then realize I've done something stupid and have to redo it all.
The big one, of course, is going to be interpolation, which I had kind of been dealing with up to this point by making mystic passes at it and chanting. Linear interpolation is simple, obviously, but there's no way on God's green earth that it will ever look right. Interpolating correctly is likely going to involve some calculus of one sort or another, and I need to figure out a way to specify an interpolation function as part of each keyframe's specification, just as I'm currently specifying a relative duration to the next keyframe.
Maya uses a simple system (from the user's point of view) wherein you can attach handles, tangential to the curve, at any point along the graph of the interpolated frames and use them to alter the curve's rate of change around that point, via a fairly intuitive system of rotating the handles around the point. It probably sounds complicated, but when you're looking at it graphically it's very obvious. I haven't thought too hard about this yet, but I'm wondering if there's some way to specify a similar set of rate-of-change modifiers in plaintext and use that to make some simple alterations to the rate of change between keyframes.
Or is there a better (simpler) way? I'm not quite sure yet. Probably need to consult some references.
Now to find time between my other assignments to work on fun, challenging stuff like this. Programming some wacky stuff for Theoretical Comp-Sci while simultaneously learning Perl has taken up the last few hours of my life and promises to take up a few more before I'm done.
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.
