BotJunkie is merging with Automaton to form the best robotics blog on the Net! Please continue following our stories at our new home and update your RSS reader with our new feed. See you there!
Writing by Evan Ackerman on Thursday, 2 of September , 2010 at 12:15 am
The robotics journal Autonomous Robots has its own blog, which is intended to take the hardcore robot news from the journal and make it a bit more reader friendly. They also link back to the journal articles, should you need a little of that hardcore techy info. Yeah baby. Anyway, looking back through some of their posts, I found these vids of LittleDog exhibiting some new learning behaviors.
While it’s best to develop a robot that’s capable of adapting to new situations, after the robot explores the world for a bit, new situations (in the general sense) stop showing up as often. So ideally, you want a robot that’s able to recognize a situation that it’s already experienced, and apply those past experiences without having to start figuring out what to do from scratch. To this end, Martin Stolle and Christopher Atkeson are developing a system that allows a robot like LittleDog to first recognize features that it’s seen before (like walls or gaps), and then access a library containing a sequence of actions that it has successfully applied to solve similar situations in the past. LittleDog can then alter those actions to apply them to the current situation rather than attempting to compute an entirely new action sequence. It’s faster, more efficient, and I imagine more successful since LittleDog is building on past experiences that worked as opposed to trying something entirely new.
After the jump, another LittleDog video, just because. (Read more…)
Writing by Evan Ackerman on Wednesday, 1 of September , 2010 at 12:48 am
Robot plants are not new to BotJunkie, but creepy ones are. Not that this robot plant is intended to be creepy, but like everything in the Uncanny Valley, it just sort of ends up that way. Or maybe it’s just me.
Each of the plant’s 169 artificial leaves is controlled by a piece of shape memory wire. When cameras mounted above the plant see your hand move over it, it signals the plant to shimmy its leaves in the same area in response to a ‘virtual wind.’
Plant (that’s what it’s called, “Plant”) was designed by Akira Nakayasu, and will be on display at Ars Electronica 2010. Pic of Plant sans leaves, after the jump. (Read more…)
Writing by Evan Ackerman on Tuesday, 31 of August , 2010 at 12:52 am
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:
Writing by Evan Ackerman on Tuesday, 31 of August , 2010 at 12:05 am
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!
Writing by Evan Ackerman on Monday, 30 of August , 2010 at 12:55 am
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.
Writing by Evan Ackerman on Monday, 30 of August , 2010 at 12:45 am
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!
Writing by Evan Ackerman on Monday, 30 of August , 2010 at 12:24 am
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.
Writing by Evan Ackerman on Friday, 27 of August , 2010 at 12:21 am
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.
Writing by Evan Ackerman on Thursday, 26 of August , 2010 at 12:59 am
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.
Writing by Evan Ackerman on Thursday, 26 of August , 2010 at 12:15 am
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.