Below are the graphic files of the layout we used for the laser cutter. The idea was to get as much mileage as possible out of each 12" by 24" piece of plywood!
Check it out on page 61 of the PDF (the page numbered "50").
]]>Below are the graphic files of the layout we used for the laser cutter. The idea was to get as much mileage as possible out of each 12" by 24" piece of plywood!
Early in the project, I decided it would be a good idea to design an entirely new blimp control board, so that we would have a lot more control over what happens onboard each blimp. For projects like this, it is definitely good to see whether you can just purchase a canned solution, or if you will have to build it completley from scratch. Choosing either extreme is probably a bad choice.
With this PCB design and the accompanying firmware that runs on it, we ended up a little more on the "from scratch" end, but now hopefully others can leverage our work. We used expressPCB to produce our boards for a very reasonable charge, accompanied with fast delivery. Our final design is available for download. You'll need the (free) design software from expressPCB to open and manipulate the designs. An accompanying schematic is also available.
Now, in terms of features, this PCB has a quite a lot packed into a relatively small package:
Not bad for a first hack at a PCB, right?
]]>
The demonstration has concluded, and not without a bit of unintended excitement. (More on that soon, with photos and eventually video.) The project has concluded, but the conclusion is a soft one, and we will continue to broadcast blimpbot details here. Perhaps a flurry of such details as we wrap things up. All of our designs and much of our software will be available soon.
]]>
Our demonstration will be held in the Computer Science & Engineering Building's central atrium on North Campus. Just walk in and look up! Prior to our demonstration, the other GROCS projects will be presented in Design Lab 1 in the Duderstadt Center.
More info on that here.
]]>
On another note, for software developers in particular, I have been impressed by the "It Just Works" (IJW) C++ unmanaged / C++ managed interoperability in Visual Studio 2005. Read on if interested. IJW is the name given to the ability to let unmanaged code access managed objects, and to let managed code seamlessly instantiate and call unmanaged objects. The upshot of this is that you can avoid expensive copy operations when passing data between the two realms. This is special to Visual C++, you can't do it with Visual C# or any of the other managed languages.
For the Blimpbots project, we're using a little bit of this to call several unmanaged libraries, including Intel OpenCV, and the SURF keypoint detector. For starters, you can mark any unmanaged code blocks with a #pragma unmanaged directive. Then, within managed C++, you just call the unmanaged libraries as you normally would, as long as you're passing value types. If you want to pass arrays or reference types, you first use a special pin_ptr syntax to tell the garbage collector not to mess with some block of memory temporarily, and then you just call the unmanaged code and pass the pointer. I'm actually not quite sure how this is accomplished behind the scenes, but, it just works, and has been quite helpful!
]]>
I don’t know if you all could tell, but during the past week, we’ve been on spring break. Before we left though, we had a design review with all the other GROCS groups and a few interested members of the public. We gave a simple presentation outlining our project. Then we ran a relatively successful hover test, where we used a single camera and a computer running SURF to keep the blimp more or less in one spot vertically (We kept it off the ground and the ceiling anyway). Then we passed out a questionnaire to spur some discussion on the project. Here are some of the suggestions we received from the questions we asked:
-Predator/Prey- one blimp is chasing the others. Possibly if the “Predator” blimp “gets” another blimp by getting too close to it, that blimp has to descend to a certain altitude.
-Tag- a variation on Predator/Prey might be “tag,” where the “predator” switches when it gets close enough to another blimp, “tagging” it. Possibly the blimp’s LED comes on or changes color.
-Herding -another version might be “herding” where one blimp tries to “round up” other blimps that are trying to avoid it.
-Pack pursuit- The opposite of herding, multiple blimps pursue one blimp. An example that kept coming up was of a girl at a club being pursued by a bunch of guys. (Obviously, some people were already thinking about spring break ;-) )
-Patrolling behavior- The blimps run a set course, which has the possibility of evolving into Shriner-car-style coordinated movements (figure 8s, clover leafs, etc.)
-Swarm/flock- The blimps obey simple rules for their motion creating a complex and ever-changing pattern of movement
-Target chasing- The blimps pursue aerial targets or the blimps react to a target on the floor, be it a specific object, a hat, the beam of a laser pointer or groups of people. Blimps might cluster around the object or just change their patterns of movement according to the position of the object.
-Noise chasing- The blimps move to the loudest or quietest point in the room
-Stochastic self assembly- The blimps have to follow 5-10 simple rules
-Voice commands- The blimps react to voice commands
-Scrabble- The blimps attempt to spell a word or words (using letters painted on the blimp’s side or an LCD/LED display), possibly controlled by some sort of user interface
-Dance- The blimps create aesthetically pleasing patterns. This may only be realized in time-lapse video, or it could may be seen by creating an image of the paths of the blimps using the trail of LEDs attached to the blimps might make over the period of say, 40 minutes.
-Follow the leader- The blimps follow a “Lead Blimp”
-Mirror movement- Two sets of blimps mirror each other’s movements.
-Buddy system- The blimps move in pairs or families. Or even in trains.
-Collector- A version of Predator/Prey where the “Tagged” blimps have to follow the “Predator”
-Relax mode- Blimps fly slowly
-Pouty mode- Blimps sulk in corners
-Spin mode- Blimps rotate 360 while maintaining their position
-Zone defense- Blimps defend their “territory” while trying to muscle other blimps around
-Dive bomb- Blimps climb as high as possible, then descend as quickly as possible (Probably not all that exciting with LTA craft…)
-Docking- Blimps navigate to a pre-determined point
-Disease- Blimps have one color LED displayed. A “diseased” blimp is introduced displaying a different color LED. When it gets close enough to a “well” blimp (without actively pursuing it) that blimp’s LED changes color as it gets “diseased”, and is also able to pass on the “infection.”
Should we focus on allowing users to define behaviors (which may or may not be interesting), or on having more pre-programmed, interesting behaviors.
-There was generous support for interesting pre-programmed behaviors over heavy user interaction, especially if user error could lead to technical problems and the system crashing. Literally.
-Perhaps you could just control the lead blimp, and the others could follow it using swarming rules
-Perhaps the user could just control which blimp was the “lead” blimp
-Perhaps the user could simply switch the blimps from patrol to swarming behavior, either by flashing a light or making a sound?
-Simple user controls will probably be the most engaging
-It might not matter what the behaviors are as long as they aren’t predictable
-User defined behaviors should have an immediate response, so this likely restricts those behaviors to trivial changes, like the colors of LEDs
-Wagering on the “performance” of individual blimps (I think this might require a Vegas simulcast…)
-A combination of some kind of low-level user control that modifies a pre-programmed behavior.
What kinds of things could we add to the blimps to make them appear more “lifelike”.
-Why not use them for guerrilla marketing?
-Could the blimps somehow be used to make paintings? Could they drop paint?
-If they flew very low, it would be easier for people to interact with them.
-Each blimp should have it’s own color
-Each blimp could behave differently, fast/slow, like to fly high, like to fly low
-Making each blimp look different might give them their own identity
-Breaking up the outline of the blimp shape might make them look more interesting
-Use the blimp’s LED to reflect it’s personality and/or emotional state
-Use the blimps to convey a bigger message.
-Use natural materials if possible, and consider things resembling scales, fur, etc
-Aesthetically, the blimp prototype is already very cool.
-Sorry, I don’t know enough about how “live” blimps behave to comment.
-Names and personas, for each blimp, perhaps displayed on the NET or on posters? It would be nice to be able to say, “Oh my goodness! Hank is chasing Bertha! That rascal.”
-Eyes could reflect different personalities (LEDS?)
-Could they make different sounds?
-Their shape evokes fish…
-Reaction to the environment, being aware of people/noise in the room
-Additional balloons resembling appendages or eyes might give added
buoyancy and suggest other forms.
It turns out that we can capture all of these properties in a 3x4 matrix, P. The matrix is set up such that, when postmultiplied by a 3D coordinate, the product is a 2D coordinate. That is, where x and X are 2D and 3D homogeneous coordinates respectively,
x = PX
Algorithms exist to automatically compute P, but let's start with a manual example. Let's think about a single 3D point X at coordinates [x,y,z]=[1,1,1]. If the camera was sitting at coordinate [1,1,0], and facing along the z-axis, this point it should be right in the center of view. If the camera had a resolution of 640x480, this means the point X should show up on the image at 320x240.
For a moment, let's ignore the camera's intrinsic properties and just figure out how to account for the camera's position C=(1,1,0) and orientation (facing straight along the z-axis). We can do this in two steps -- shifting the camera -- and then rotating it. We can achieve this by using a homogeneous translation followed by a rotation. So we translate by C. Actually, we translate by -C because we're moving the point X rather than the camera. What about the rotation? Well, we have already implied that the Z-direction is "straight ahead" for the camera. So it turns out the camera is already facing the right direction, and we can use the identity matrix for the rotation, R=I. These two operations produce a matrix operation X' = RTX, where x' is the position of the fixed-frame point X in the camera's reference frame. R and T are the aformementioned rotation and translation.
In MATLAB, noting that X has an extra "1" scale factor tacked on, we get the result we expect, X' = (0 0 1), that is, just one unit in the Z-direction in front of the camera!
R=eye(3);
T=[eye(3) [-1 -1 0]'];
X=[1 1 1 1];
X_prime = T*X
= [0 0 1]
In the above calculations, we have still ignored the fact that the camera is actually projecting 3D coordinates onto a 2D plane, and that the camera has other intrinsic properties (like focal length). It turns out that these can all be represented by one more matrix K multiplied by the other two we have already seen, yielding the full camera matrix P = K*R*T. The definition of K is shown below. The camera has a focal length, which we'll just arbitrarily specify as 35.0, and two other intrinsic parameters k_x and k_y, which we also arbitrarily specify as 1.0 for now.
Now we have everything to fully-specify our camera, so we compute the result of the multiplication, in MATLAB,
P =
35 1 320 -36
0 -35 240 35
0 0 1 0
Now let's see what this camera can do. Remember all along we've been trying to take our coordinate X=(1,1,1) and turn it into camera coordinates, which we know from experience to be (320,240). So we will "take a picture" by premultiplying X by P, and we get precisely that:
>> P*[1 1 1 1]'
ans =
320
240
1
Actually it may be confusing that we have that extra "1". Again, this is a scale factor, and as long as it is "1," the coordinate is what we would expect. The K matrix is responsible for the camera's projection into 2D, which requires a division that will in general yield non-unit scale factor. In this case, we simply normalize the coordinate by dividing by the scale factor, e.g.,
>> ans/ans(3)
Next, I'll apply the camera matrix to visualize something other than a single point, and then we'll show how the camera matrix is crucial in using multiple 2D images to reconstruct 3D scenes.
We have been discussing the possibility of using infrared LEDs to help out the tracking a bit. After hearing that most digital cameras actually pick up IR, I did some really simple tests to see what is possible.
The simplest way to see if a camera picks up IR is to point a remote control at it, and see if it lights up in your image. As you can see in the left image, it does that in our camera-- that light is not visible to the naked eye. For tracking, though, we need to filter out everything except IR-- that way, the image is much simpler, and any IR LEDs on our hardware will pop out. IR filters may sound exotic, but that's what those dark panels in front of the sensors on remote-controlled electronics are.
I happened to have one of those panels around, and tested the remote again, from behind the filter (on the right). Now, the IR coming from the remote in much more obvious.
The image is not as good as a "real" infrared camera setup, but might work well for tracking. It's not certain we'll use infrared in the final system, but some IR LEDs are on their way so we can test this more.
]]>