Category Archives: Little Robots

Posts and materials about Little Robots

A change in focus

So I gave Drupal a try but found that I had no patience for actually writing HTML or messing with the hundreds of little plugins… blah. How things have changed… so.. hello WordPress!

A couple weeks ago, I had decided to enter the Exile Villify video contest. I started down the road of modeling out the various elements that I wanted in the video … but a combination of lazyness and Rock Band 3 got in the way.

I did learn an awful lot about the subdivision surfaces in blender, though… so I can’t say that it was a complete waste of time…  I found that the objects in this scene, though they look primitive, are actually pretty complex… The turret in particular, with its rounded shape yet sharp edges.  I definitely had to get competent in cinching edges and marking seems.

Since acknowledging that I won’t make the deadline for the music video, I’ve decided to morph the entry in my In-Flight Projects page to a more general non-Aperture Science branded set of robots making music.  It’ll be a good excuse for me to mess with the Structured Audio bits of MPEG4.

 

Just give me a Seña!

Seña Skeletal designThe design for the robot, Seña is influenced largely by the Turret from Portal 2.  While it may not be obvious from this basic skeletal image… you’ll see.  When the white shell drops on over the rounded body, the relationship will become more clear.

If you notice the front legs are on a hinge giving her the ability to extend or contract the front legs independently.  I’m hoping that this will help give the robot some form of expressiveness in anotherwise static design.  The rear wheel can’t really contract, but can rotate giving Seña’s tadpole design steering capabilities.

The only other piece of Seña that I definitely have to model out is her eyepiece.  Seña will be a cyclops design with a single camera mounted much like the old observatories were.  The eyepiece will be able to rotate upward and downward along a fixed track.  An important aspect of the eyepiece will be it’s ability to express emotion.  In both Wall-E and in the two robots from Portal 2, we see a remarkable amount of expressiveness in the eyes, not just through aperture movement and focus, but through lens coverings and general eye motion.

Hopefully I’ll come up with a good design.

Seña Eye Detail

Seña Eye DetailI think that this will be the basic eye design that I go with for Seña.  She’ll have a single camera lens style eye with a traditional looking aperture that has protective coverings which allow it to open or shut.  I’ll assume that when shut, the lens cleans itself somehow.  I’ve also added four sunshade petals which will be independently posable.  These are really not functional in my opinion, but they aught to add some level of expression.The entire eye assembly itself moves vertically along a covered track not unlike the telescopes at large observatories.

At first I wanted to detail out the entire internals of the assembly like I did with the skeleton, but then I remembered, I’m not actually designing something to build… I’m simply sketching out what something looks like to model.  The actual machine, while it needs to suspend disbelief doesn’t actually have to function in real life.  Oh the joys of make believe!

With this bit done, I should be able to start some initial models of this robot.  As the model comes together, I’m sure edits will take place.  It’ll be interesting to see just how closely my finished product resembles the actual concepts.

Robo Optics

I’m finally getting into the grave details of modeling robot optics.  There is something that I’ve noticed about sci-fi movie optics that make no real sense logically, but they definitely add drama and emotiveness… the idea of eye color.

In just about all movies we’ve seen featuring robots, bad robots have red eyes.   Often we see as a robot makes a transition from being a good robot, the lights on that robot itself change from say blue to red.  I decided to add this color change concept to the robot optics I’ll be using for Little Robots.

The way I’ll do this is, behind the aperture, I’ll have a set of three colored lamps.  As I want to express different emotional states, I’ll dim or intensify the corresponding colors.  I’ll probably look up the Mood Ring color scale and just use that as my palette.   The lights themselves will reflect off a white surface at the back of the optical cylinder and should show up through the aperture of the robot.  Nice and tidy.

 

Speaking of apertures… I discovered that well… I had no idea how a mechanical aperture worked.  Instead of chickening out and using something lame like a square aperture, I messed around and discovered that really, apertures are just little sheets of rectangular metal (well, more like trapazoids) that rotate about 15 degrees.  Check it out:

Here you see my aperture which is made up of eight rectangles.  On the left, it’s in its closed state.  On the right, I posed it open.  Each aperture blade rotates a small amount in place and whammo… you have an open aperture.

Rigging, It’s tougher than it looks…

So I spent the last few hours trying to figure out why my aperture lines up correctly in one pose but not in another.  I’m sure that there’s a simple solution to the problem… and looking back I’ll think, “D’oh! yeah, that was a dumb newb mistake.”   In a previous life, I was told that experiences like these are “learning opportunities.” sigh.

For anyone curious what a vertically slatted optical assembly looks like rigged in blender? Check it out… It’ll change over the next few days I’m sure, as I figure out my alignment issue, but to date, this is the most complex rig I’ve ever done. Go me!

So what you’re looking at here are the rig “bones” for the aperture which allow the aperture to open and close.  Behind it, you see a fan-shaped set of bones which control the segmented slats above and below the eye that telescope in or out depending on the inclination of the optical assembly itself.

.The specific problem that I’m having at the moment is, if I incline the eye, the aperture drifts slightly to the left.  I’ll experiment on it this weekend and hopefully find a good solution.  Learning Opportunity, right?

In the meanwhile, I actually did a little bit more concept design work around how Seña will express emotions.  Here are four basic emotions that I tried to express using the eye that I designed for her.

Actually drawing out the eye pieces in different emotional states, it showed me just how important coloration will be.

See if you can figure out what these emotions are…

Seña Wireframe

She’s still untextured, and not all of the mesh is there… but we’ve got a good, healthy start!

Like most designs, as the pieces come together, I’m sure changes will need to be made.  The overall curvature of the front will be one alteration that I need to make.  This particular change is necessary for the eye to rotate through its frame properly.   Another change that I want to make is to the rear wheel.  I have a double-wheel in this design, but I think that I want to change that to a single, larger wheel.

I suspect that the texturing of the robot will be fun… but to get to that point, I’ve got to do UV Unwrapping.  This has got to be one of THE most arduous tasks ever conceived.  It’s more or less the same problem as representing a round globe on a flat map… except instead of a globe, you have this robot.

Looming on the horizon is the task of sound.  What’s this robot going to sound like?  I don’t just mean the whirring of motors or other familiar sounds… A great deal of effort in the design was to make Seña emotive… and to complete that task I need to come up with a voice.  No, this voice isn’t going to speak English, but in the tradition of R2D2, or the cute little robots from Silent Running, I’ve got to come up with a distinct, synthetic voice.

My current plan is to use a sine wave that’s got a base frequency.  The base frequency will change a little up or down depending on the emotion being conveyed.  This base frequency will have “words” added to it as bursts of other sine waves added in. The first few attempts may simply be a sped up and perhaps reversed Morse Code.  I realize that it’s unlikely robots would communicate through something as archaic as Morse Code, but screw it, I’m writing fiction here!

Messing with Structured Audio

It’s time to seriously consider what Seña will sound like. To accomplish that, I’ve started messing with structured audio.  What does that mean?

It seems that part of the MP4 standard includes a section involving programmatically generated sound.  Basically, making synthetic sounds with programming.  It’s visually pretty drab, but if you’re into coding like I am… it’s pretty cool.

The audio programming language takes 2 major components, a SAOL file, and a SASL file.  The SAOL file is where you define your “instruments” and the SASL is where you sequence your instruments playing notes…

I made a test SASL and SAOL based on the example scripts they provided.

instr sine_tone(f, a) {
    asig x, y, init;

    if (init == 0) {
        init = 1;
        x = 0.5;
    }

    x = x - f * y;
    y = y + f * x;

    output(y * a);
}

Here I added two parameters, f and a. This allowed me to control the frequency and amplitude of the approximated sine wave created by the x= and y= expressions.

To actually play the instrument, I made a SASL file:

0.25 sine_tone 0.50 0.196307 0.10
0.50 sine_tone 0.75 0.296307 0.10
0.75 sine_tone 1.00 0.396307 0.10
1.25 sine_tone 1.50 0.196307 0.20
1.50 sine_tone 1.75 0.296307 0.20
1.75 sine_tone 2.00 0.396307 0.20
2.25 sine_tone 2.50 0.196307 0.35
2.50 sine_tone 2.75 0.296307 0.35
2.75 sine_tone 3.00 0.396307 0.35
3.25 end

Here you see I invoked my “sine_tone” instrument with various parameters. The leading number and first parameter represent start and end times in seconds. The last two parameters map to the f and a variables of my instrument.

I wasn’t able to get the audio player plugin to work properly with the resulting .wav file nor was I able to get it to play with an itunes converted m4a…

UPDATE: I managed to get a proper mp3 toolchain going. I might describe that in more detail on Thursday. For now, here is a proper flash audio player

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

Structured Audio C Major Scale

I’m continuing to experiment with MP4-SA.  This time around I have a bit more refined infrastructure built.  The major trouble that I had with my previous audio file, It needed to be refined from the raw .wav generated by sfront.

My end goal was to have a process by which I could write instruments and score files and in a single command produce a properly ID3 annotated mp3 file that I could then use to play via the WordPress Audio Player.

Using macports, I was able to quickly install Blade’s MP3 Encoder, and id3tool.

Once all of these packages were installed, I wrote a simple template bash script that takes all of these disparate pieces and forms voltron.

The result is the following, very modest, audio file rendering a simple C Major scale…

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

Yeah it’s still rough… I’m not entirely sure what the popping sounds are after each note.  It probably has to do with the signal being cut off abruptly… That’s something I’ll have to work out in the instrument file itself…

Ok. Well, what does a C Scale look like in MP4-SA?

0.00  @INSTRUMENT@ 0.40 261.626 0.8
0.50  @INSTRUMENT@ 0.40 293.665 0.8
1.00  @INSTRUMENT@ 0.40 329.628 0.8
1.50  @INSTRUMENT@ 0.40 349.228 0.8
2.00  @INSTRUMENT@ 0.40 391.995 0.8
2.50  @INSTRUMENT@ 0.40 440.000 0.8
3.00  @INSTRUMENT@ 0.40 493.883 0.8
3.50  @INSTRUMENT@ 0.40 523.251 0.8
4.50 end

The strange @INSTRUMENT@ markup is part of my tool chaining.  Prior to running the sfront program on this file, my shell script replaces all occurrences of @INSTRUMENT@ with the actual instrument being played… in this case it was a sine wave.  The first number after the instrument turns out to be duration of tone.  In my last post I had mistaken this field to be stop time.  The 2nd value is frequency.  This has also changed from my first attempt… instead of a fairly arbitrary decimal value, this is an actual measure of frequency in Hertz.  Finally we have amplitude which pretty much changed the same…

To facilitate the changes in what the parameters mean, I also changed the basic sine instrument that I wrote.  Here is the new, improved sine

instr sine(f, a) {
   asig x, y, init, arate;
   if (init == 0) {
      init = 1;
      x = 0.0;
      arate= f * 3.14159 * 2 / 32000;
   }
   x = x + arate;
   y = sin(x);
   output(y * a);
}

You can see here, that I’m actually using a for real sine function now. The arate variable computes the x value of sine based on the sample rate of the composition, in this case 32000.  In reality, this should be a global variable of some kind but I could not seem to get that to work.

One thing I will probably do in the future is change the frequency numbers of each note to be aliases, much like the @INSTRUMENT@.  This will make it easier to score more complex songs.  I should also do that for note duration.

Eureka! Strange pose behavior solved!

A while back, I had posted about a strange rigging behavior that I was seeing.  I’m not sure that the description that I was terribly useful… so I decided to make a couple animated gifs to help with the visuals…

Here you see what a proper rigging is supposed to look like.  The block rotates with the rotation of the “Bone”. Now, The following image illustrates what I was looking at…

You can see here, the cube is actually moving faster than the rotation of the bone.  The exaggerated motion caused all kinds of stuff to get out of alignment.

The way you associate the Armature or Skeleton to an object is you set the Armature as the “Parent” of the object.  In this case, the object is the cube.  You do this by simply selecting the cube, then the Armature and hitting CTRL-P (You can also parent by going through the menus).

When I created the simplified case of the single bone and a single cube, it worked just fine.  On a hunch, I decided to un-parent then re-parent the object and armature… and voiala! the problem was reproduced.   It turns out that in Blender 2.5, you’re not actually “parenting” you’re setting a modifier on the object… so clearing the object’s parent does NOT clear its relationship with the armature.  When you then re-parent the two, you create a SECOND modifier between the object and the armature, so any changes to the armature are magnified 2x… which is the behavior you see in the 2nd image.

Okay. Well, this is all well and dandy, but if you can’t un-parent, how do you get rid of the armature to object relationship?  It ends up in the object modifiers tab.  Here’s what it looks like if you’ve got an Armature associated multiple times with an object…So… all you really have to do at this point is figure out which of the two modifiers you want and X the other one(s).

In the situation with my aperture, I had created 3 modifiers.. so the pose was affecting the object three times as fast.

 

Seña’s Final Eye Rigging

I took some time over the Labor Day weekend to finalize Seña’s eye rigging.  As you can see from the image to the right, the rigging itself is made up of something like 25 bones.  Crazy but awesome.

A particularly pleasing aspect of finishing this rig is, it satisfies all of the requirements that I set forth in my previous post about Eye Detail.  This means that I wasn’t forced to compromise with the features I wanted… I was able to figure it all out.

While rigging the “eye petals” (the four sun shades around the outside of the eye), I ran into another peculiarity of blender‘s armature system.  Let me describe the setup… The eye petals each have a vertex group (upper petal, lower petal, left petal, right petal) and each vertex group has an associated bone in the armature (they’re the largest ones in the image above).  Whenever I’d rotate a petal, though, it’d deform in very peculiar ways.  Below is a simple rig that reproduces the problem…

For the first say, 20 degrees of rotation everything looks fine.  You’ll notice though as the bone is rotated, the box it rotates starts to get smaller and no longer seems to follow the track of rotation.  Grrr… what’s causing that??!

Before I present the solution, I need to show you how the vertex groups are set up so that I can explain what it is we’re seeing here…

You can see that I have two vertex groups… “Upper Box” represents the box we’re trying to move and “All Boxes” is a group containing both the upper and lower box.  “All Boxes” is associated with the parent bone (behind blue one) and “Upper box” is associated with only the box that we’re moving.

Because the upper box is being influenced by two different bones at the same time, their overlapping influence on the vertexes of the box causes the strange behavior.  The solution is to remove the upper box from the “All Boxes” vertex group.  Once I removed the overlap in bone influence everything works as expected.