With just a little bitty Army contract, you can take that robot paintball turret that we saw a week or so ago, mount it on a QinetiQ SWIFT (an intermediate prototype between this and this), and rig it up to be controlled by head movements. It’s not just for the cool factor (although there’s definitely a cool factor); head control is easy to train, easy to use, and requires no hands. They’ve got the basic system running on this sweet little indoor tank, too:

Every office absolutely needs one of those.

[ Stratbot ]

Thanks Kent!

Building robots has never been a cheap hobby, but you can offset the expense a bit simply by winning this contest sponsored by Trossen Robotics. They want you to make a robot, any robot, and as long as it’s more super incredibly awesome than any other robot ever made it’s pretty much guaranteed to win one of these prizes:

Here’s a peek at the hexapod, on the loose at RoboGames:

You’ve got between now and December 1 to come up with something awesome, and of course, the real prize is that you’ll certainly get featured here on BotJunkie if you win. Good luck!

[ Trossen DIY Contest ]

We were among the very first to see the latest generation of Stanford’s gecko-inspired climbing robot, Stickybot III, earlier this year at the Stanford National Robotics Week event. While Stickbot III could stick to surfaces, the climbing technique (one of those harder than it sounds things) was still in the works. Just recently, they’ve figured out how get it climbing at a brisk 5 cm/sec, as you can see in the video above.

The tricky part now is making the robot completely steerable. To do that, the feet need to be able to rotate around to point backwards, since the adhesive is only sticky in one direction and won’t stick at all without some force being applied (i.e. the weight of the robot). So for example, in its current incarnation Stickybot III can’t climb headfirst down, since its sticky feet only work in the up direction. Therefore, the feet need to be able to rotate so that they’re always pointing up irrespective of the orientation of Stickybot itself. It’s what geckos (real ones) do, check it out:

It must be a mixed blessing to be developing a robot that’s so closely inspired by an animal. On the upside, if you need a clue about how to do something like turn while climbing, you can always just take a peek at the gecko itself. But at the same time, the actual gecko is going to be doing everything you want your robot to be doing, except way better and without trying.

At least it’s not cuter. And incidentally, Stickybot III is a she.

[ Stickybot ] VIA [ Stanford News ]

Thanks Salomon!

CMU just posted this new vid of their Snakebot (Modsnake) climbing a tree and looking around. It’s still tethered, but it’s a snake, so that just makes it seem more snakey. This isn’t the first video we’ve seen of CMU’s Snakebot climbing stuff, but it’s the first one we’ve seen outside of the lab, so that counts for something, right? Sure!

[ CMU Biorobotics ] VIA [ Hizook ]

The last few vids we’ve posted on Boston Dynamics’ BigDog haven’t shown much in the way of new capabilities, although DARPA has asked for some upgrades. Back in May (I think, although the video wasn’t posted until now), Marc Raibert, founder of Boston Dynamics, gave a talk at Stanford on the current progress and future plans for BigDog. It’s an over an hour long, but (as you might expect) the juicy bits come in towards the end regarding the future plans. If you don’t have an hour or so, I’d recommend starting in at about the 46:50 mark, where you get to see some video of a quieter BigDog with an electric motor, among other things. If you don’t have time for even that, here’s a summary of what I thought were the most interesting bits:

-Marc Raibert says he’s inspired by mountain goats, which is pretty daunting when you’re designing a quadrupedal robot.

-Robots vs. mules: mules are better, except: they can only carry about a third of their body weight, they don’t take direction well, and they’re not easy to warehouse.

-That video of BigDog slipping on ice and recovering? It wasn’t programmed specifically to deal with slippery surfaces, and they didn’t even know it was icy out, they were just shooting some other test video and it happened to cross a patch of ice, recovering using its standard dynamic balance programming.

-BigDog is able to run (actually run, including a stride phase without any ground contact) at a little bit over 6 mph, although they’re still working on its balance while running.

-Boston Dynamics has two working BigDogs, both of which you can see in action at 30:40 (this is new video). Raibert wants to get 7 or 8 of them together to go dog sledding (!).

-BigDog can’t yet get up on its own, but they’re working on it… The next generation will have the hip (or shoulder) joints positioned outside of the body and higher up, with an increased range of motion that will allow the robot to get its legs under its body, which the current generation can’t do.

-Kinematically, the orientation of BigDog’s legs (knee front or knee back) just doesn’t matter. They’re able to take the legs off and swap them around.

-The noise BigDog makes is “much worse” in person. The videos “don’t do it justice.”

-Electric motor BigDog still sounds like bees (although they’ll be able to mute it completely), only runs for 10 minutes, and is slightly underpowered… They’re contemplating a “hybrid” version, where you can switch to silent operation for 10 minutes and then back to gas.

-BigDog can follow people autonomously using a scanning LIDAR system, engineers say it’s “really scary to have the robot following you going down hills” (ha!).

-There’s no redundancy in the walking system, “BigDog goes down when you shoot off a leg.”

-The biggest challenge so far has been making the system able to run in the heat (due to the engine).

There’s also a little bit of an update on PETMAN; unfortunately, the outtakes weren’t approved for webcast (neither, for that matter, were the BigDog outtakes. FROWNY FACE.). But you do get to see a CAD rendering of PETMAN:

Marc says PETMAN freaks him out a little bit because of the whole Uncanny Valley thing, but he’s trying to be mindful of that while designing PETMAN.

At the end, Marc Raibert even gives a shout-out to that brilliant BigDog parody video… He says that his new metric is how many views his BigDog YouTube videos (and their parodies) receive.

[ Boston Dynamics BigDog ]
[ Stanford @ YouTube ]

In an incident that’s already been blown way out of proportion by headlines like “ROBOT KILL-CHOPPER GOES ROGUE above Washington DC!“, an MQ-8 FireScout temporarily lost its communication link and entered restricted airspace around Washington DC before operators shifted to another ground control station and brought it back to base.

Obviously, this isn’t the way it’s supposed to go… When UAVs lose communications, they’re supposed to either head back home, or loiter in place until they receive further instructions. So what happened to FireScout? If you guessed human error, you’re at least partially correct:

The series of events that prompted the aircraft to wander into restricted airspace around Washington, DC., “had to line up just perfectly,” says Rear Adm. William Shannon, Navy program executive officer for weapons and unmanned systems. He attributes the problem to a “software logic flaw.” In this case “We found a software anomaly that allowed aircraft not to follow its preprogrammed flight procedures,” Dunigan says. “We have identified the issue and have aircraft operating restrictions that will prevent this from happening again.”

There could be an element of operator error in the incident. Shannon says that a command was given by the operator just as the air vehicle would have shifted to its preplanned return-to-base procedure. So, the introduction of the command apparently played a part in the mishap.

It’s also worth noting that as soon as FireScout realized something was wrong, it started squawking to local air traffic control, who could route other aircraft around the area if necessary.

Although this was undoubtedly an ‘incident,’ it illustrates why I’m so optimistic about autonomous robots, military or not. I mean consider what happened… An unforeseen and improbable series of events occurred that caused a communication loss and FireScout went somewhere it shouldn’t have. The robot realized something was wrong, notified air traffic control that it was in distress, and responded directly when communication was restored. The issue was then identified and resolved, end of story.

FireScout has been undergoing testing for a long time, and this is why it’s been undergoing testing for a long time. FireScout works, and it works well… Well enough that it takes a software bug plus human error in a very specific situation to get it to do anything it’s not supposed to, and even then, it doesn’t do anything crazy or excessively dangerous.

Of course, there is always the potential for other unforeseen issues to cause similar errant behaviors. But that’s kinda the way everything works, whether it’s a robot’s software or a human’s software. The advantage of robots, however, is that issues (when they arise) can be identified with certainty and resolved with an equal amount of certainty: FireScout won’t make this mistake again, and neither will any other FireScout running this software.

And, well, there’s always Plan B.

[ Aviation Week ] VIA [ The Register ]

We already knew that in some specific cases, robots are better pilots than humans, but this footage from Rockwell Collins really drives home the fact that under extreme circumstances, there’s just no out-flying a robot. This small autonomous demonstrator suffers all kinds of damage, but not only does it not crash, it keeps on flying its mission and then lands. For the record, humans are pretty adaptable too, but this next one takes the cake:

Let me just reiterate what’s going on here: the aircraft has no aileron control and is rolling randomly, but is still able to navigate in three dimensional space (it’s flying in a big circle) by using its other control surfaces in conjunction with whatever its roll angle happens to be. At roll speeds of up to 500 degrees per second, there is no way a human could do this, but to the robot, it’s just not that big of a deal.

This technology is great for UAVs, of course, but personally I wouldn’t mind in the least if every airplane I flew on had this capability sitting dormant in a subroutine somewhere until the wing falls off and everybody starts to PANIC and then realizes oh, it’s fine, apparently we don’t need that wing anyway. Next up: cut-rate airlines invest in adaptive intelligent flight control technology, auction off wings and tails.

[ Rockwell Collins ] VIA [ I Heart Robotics ] and [ DIY Drones ]

I love Microsoft Surface. I’ve been in love with it ever since the hands-on demo I got back at CES 2008. Since then, Surface has trickled into a few retail settings (and become the most epic D&D tabletop evar), but it shines when it comes to practical applications, too. Mark Micire at UMass Lowell has taken a Surface table and set it up to control a small swarm of (as yet hypothetical) robots through one of the most simple and effective interfaces I’ve ever seen, a hallmark of Surface. Not only can you just tap, touch, and drag to command as many robots as you like, but if you need to take personal control, the interface for that is extremely slick, Minority Report style. Furthermore, the control interface is also the display, making it fast and intuitive to change commands based on new data. Although it’s not implemented here, a logical next step might be to update the Surface display based on real-time mapping data from the robot swarm.

Another advantage of this kind of system is that you can combine multiple types of robots returning all kinds of data into one seamless command and control display. Like, imagine that some of the swarm consisted of UAVs, and you could add a Z coordinate and send them off to scout ahead. And maybe they have radar or LIDAR, and then that data gets overlaid on the display as well. Sort of like this, except real. Am I gushing? I think I’m gushing. But this is totally cool, and there’s tons of potential. It’s not even that there’s anything that innovative going on here, strictly… It’s just that Surface is able to merge existing hardware and existing controls into a new interface, which makes all the difference.

While I wouldn’t say that interface is necessarily overlooked when it comes to the current generation of robot designs, I do think it’s under-emphasized. People tend to focus on making a totally awesome robot, but unless it’s entirely autonomous, the effectiveness with which the robot operates is dependent on (and in some cases constrained by) the ability of the human user to communicate what they want to the robot quickly and precisely. And even if it IS entirely autonomous, some directions are generally required. I won’t belabor the many examples of this, but I would suggest that a mediocre robot with a good control system is substantially more effective than a good robot with a mediocre control system.

[ UMass Lowell Robotics Lab ] VIA [ Microsoft Robotics Blog ]

Getting oil out of water isn’t that hard, on principle. What is hard is getting a huge amount of oil out of an even huger amount of water. If you think about it, this is really a perfect task for a swarm of robots, since it’s simple and repeatable and just needs to be done over and over (and over and over and over) again. With this in mind, MIT’s Senseable City Lab has created Seaswarm, a swarm of networked oil spill cleanup robots:

Seaswarm is designed to be simple, cheap, and efficient. To collect oil, the robots use a wide belt covered in a special hydrophobic nanofabric (about the consistency of a paper towel) that sucks 20 times its own weight in oil (and other pollutants) out of water. The belt moves around like a treadmill, which passes the befouled nanofabric back to be cleaned while simultaneously propelling the robot forward. The video talks about heat being used to separate oil from the nanofiber, while the description on the Seaswarm website makes it seems like the oil is squeezed out using rollers… Whatever floats your robot, I guess.

What I’m not too sure about is where all of that captured oil goes. Using their solar panels for power the bots can collect for several weeks at a time, and the more oil they collect, the heavier they’ll get, and the more energy it’ll take to keep them moving. The website does mention that the oil will be ‘digested,’ which I assume implies microbes, but they’ll either have to collect oil very slowly or have some wicked crazy hungry bugs to be able to get around the problem.

Seaswarm is designed from the water up to utilize swarm behaviors. To combat a spill the size of the recent one in the gulf, about 5000 fully autonomous Seaswarm units would cooperate for a month, using GPS and WiFi to organize themselves for most efficient coverage. And of course, you get all the usual swarm benefits of scalability, adaptability, and robustness.

While Seaswarm as a whole is currently just a concept, they have built an actual working prototype (in the pic above), which was just tested out on the Charles river in Boston, I guess because the designers figured they’d teach the robot some humility when it comes to pollution clean-up.

[ Seaswarm ]

18 May 2010: At ODP 889 (1256m below the sea surface), we happened upon an abandoned rice cooker or crock-pot and screwdriver upon which sat a large crab. The ROPOS pilot carefully opened the lid. Inside, we discovered a mother octopus with her brood of eggs! Collaborating scientist suggested adopting this creature as the Bubbly Gulch mascot. We’re calling her “Kraki.”

The ROPOS (Remotely Operated Platform for Ocean Sciences) is a tethered ROV operated by Neptune Canada. It has a maximum operational depth of 5000m, and carries five cameras plus two 7 DoF arms equipped with force feedback controllers, allowing the ROV pilot to open even the most becrabbed and beoctopused undersea rice cookers.

[ Neptune Canada ] VIA [ Fark ]