Tuesday, February 13, 2018

SOLVED: Harmony Ultimate Home no longer responds to some Google Home commands


Beginning some time since February 10, 2018, we can no longer invoke many of the Activities our Harmony Ultimate Home via voice commands to our Google Home. When we say, “Me: “Hey Google, tell Harmony to turn on DVR3,” Harmony responds by voice that it does not know how to respond.

(Learn how to configure your Google Home and Harmony hub-based remote to control your Harmony by voice commands at this Logitech Support page: Harmony experience with the Google Assistant.)


I discovered through experimentation that for SOME Activities that I have created, Harmony no longer responds to the expression “tell Harmony.”

SOLUTION: Always say “ASK Harmony.” This has completely resolved my problem.

UPDATE 2/14/2018: My symptoms are entirely related to the presence of numerals in my Activity names. See more below.


Some time after 2/10/2018, some hub-based Harmony remote systems stopped responding to certain voice requests made through linked Google Home devices.

Experimentation reveals that Harmony responds with an error message if both of these conditions are true:
  • The voice command uses the phrase "tell Harmony,"
    • AND
  • The Harmony Activity name contains a numeral or a word representing a number
Substituting "ask Harmony" for "tell Harmony" results in normal execution of the requested Activity.

Renaming the Activity to omit any numerical references also results in normal execution.


Around two days ago, (February 11, 2018), I discovered that SOME of the Activity requests sent to the Harmony Home Ultimate via our Google Home were no longer understood by the Harmony.

Me: “Hey Google, tell Harmony to turn on DVR3.”

Harmony (via Google Home): “Sorry, I misunderstood your last statement.”

Other possible Harmony responses (which vary randomly):
  • “Sorry, I don’t understand.” Ask Harmony for help to ask what I can respond to.” 
  • “Sorry, I’m not totally sure about that.” 
  • “Sorry, I don’t understand. Visit myharmony.com/google-assistant to learn what I can respond to.” 
NOTE: This is the _Harmony_ voice responding, and NOT the Google Home voice.
Curiously, SOME of the Activities could still be invoked. Here is the list of failures and successes:
  • “Hey Google, tell Harmony to turn on DVR1.” FAIL
  • “Hey Google, tell Harmony to turn on DVR2.” FAIL
  • “Hey Google, tell Harmony to turn on DVR3.” FAIL
  • “Hey Google, tell Harmony to turn on Apple TV.” SUCCESS
  • “Hey Google, tell Harmony to turn on PS3.” FAIL
  • “Hey Google, tell Harmony to turn on Chromecast.” SUCCESS
  • “Hey Google, tell Harmony to turn off.” SUCCESS
Rebooting and power-cycling the Harmony hub and the Google Home had no effect on the symptoms.

I tried altering the name of the Activity in a minor way: I changed “DVR3” to “DVR 3” and “DVr3” (noting that all the problem Activities were all-caps), but the problem persisted.

However, completely changing the name from “DVR3” to “Elephant” allowed me to invoke that Activity by saying “Hey Google, tell Harmony to turn on Elephant.” Changing the activity name BACK to the original “DVR3” reintroduced the problem (which is a great diagnostic clue).

Eventually, I tried a different verbal command. Instead of saying, “Hey Google, _tell_ Harmony to turn on [activity name],” I said, “Hey Google, _ask_ Harmony to turn on [activity name].” Success! Without making any changes whatsoever, simply changing what we say - using the polite “ask” rather than the imperative “tell” ALWAYS WORKS.

So something has changed. I’m certain that we’ve always said “tell Harmony” because since November 2017, we’ve had a hand-written sign on our AV cabinet which I wrote for my wife the first day I set up Google Home to work with the Harmony. The sign reads, “Hey Google, tell Harmony to turn on DVR3.”
Even further and more absolute proof: Google Assistant keeps a log of all your activities:
The same command which worked on February 10, 2018 fails on February 13.

Unclear is whether the change that’s taken place was by Harmony (Logitech) or Google.

For now, I’m happy to be back in business.


Thanks to feedback from Logitech Harmony forum user "john_woo," I realized that I'd entirely missed a clue that I'd put in my list of SUCCESS/FAIL Activities above. All of the Activities that result in a Harmony error response when issuing the "tell Harmony to" command have a number in them. (And to reiterate, using "ask" instead of "tell" works even with a number in the Activity name.)

Interestingly, replacing the digit "3" with the word "three" doesn't help. The error persists. To test whether the prohibited terms were digits, I tried incorporating a "30" into an Activity name. So it appears that any use of a numerical reference in an Activity name will cause the request to fail if "tell Harmony to" is also in the voice command.

Something appears to have changed in either the Harmony (Logitech) or Google code which prohibits the use of a numerical value (whether expressed as numerals or written out as a word) in a Harmony Activity name, when used in conjunction with a "tell Harmony to" voice command.


In the course of trying to find any information about this problem online (and since I just found a post from someone else from February 10, 2018, I’m guessing that this problem is too new for there to be any online information), I discovered that by using Google Assistant Shortcuts, we can eliminate having to say the “ask Harmony to” part altogether. By following the instructions starting in Section 4 of this Logitech Harmony Support page, you can shorten these commands from:

“Hey Google, ask Harmony to turn on DVR3”

“Hey Google, watch TV”

...or whatever you’d like to say to start a Harmony Activity.

(If you really wanted to, you could use a Google Assistant Shortcut to still say “tell Harmony” and have Google pass along the more polite and functional “ask Harmony” instead.”)

Wednesday, January 31, 2018

Fixing Stuttering/Jumpy Cursor Problems on Mac Pro with Magic Mouse

I love the top tracking surface of my Apple Magic Mouse - to me, it's the best-ever solution for scrolling, even allowing simultaneous scrolling while moving the cursor.

However, on my Mac Pro 4,1 (2009), cursor control has been spastic, making use of the Magic Mouse frustrating. Concurrently connected Apple Bluetooth Trackpad and wired Mighty Mouse both work normally, thus suggesting that it wasn't either the cursor control subroutines or the Bluetooth system at fault. I've kept all of them connected for years, switching around for either better cursor control or better scrolling.

Periodically, I'd look for solutions to the oft-reported problem, but none of the fixes I attempted had any effect.

Then I found this blog entry: MAC PRO 2009 BLUETOOTH FIX

And was immediately convinced that this blog's author had identified the true culprit: that the Bluetooth antenna location inside the aluminum case of the Mac Pro made for very poor signal propagation (my mousing surface is 10" from the top-front corner of the Mac Pro, and perhaps 30" from the OEM Bluetooth antenna's location inside the case). I liked the sound of the author's "BLUETOOTH FIX USING ORIGINAL BLUETOOTH CARD" solution, which mounts an aftermarket antenna on the outside of the Mac Pro's case.

As of January 2018, I found that Amazon stocks a 2-pack of both the appropriate antennas and the prescribed "pigtail" antenna cables for only $10US:

  • (2) 6dBi 2.4GHz/5GHz Dual-Band WiFi RP-SMA Antenna
  • (2) 35cm U.fl / IPEX to RP-SMA Antenna WiFi Wireless WAN Pigtail Cable
The brand name listed is "Highfine."

The fix is somewhat involved, requiring removal of the Mac Pro's CPU daughterboard and graphics PCI card. The solution also requires some real estate on a PCI mounting plate - the blog article specifies drilling a hole in a blanking plate, but all my PCI slots were populated. I chose to remove an infrequently-used adapter card for a video-acquisition box, but if I were to re-install that, I'd probably add the antenna to a USB 3 adapter PCI card. Fishing the pigtail cable through to the Bluetooth card, and actually working with the tiny U.fl connector can be challenging. 


Problem solved! The Magic Mouse now works like a . . . mouse! Performance is fluid and consistent. It was totally worth the effort.

Tuesday, June 13, 2017

Prevent Your Mouse from Scrolling Between Months in Google Calendar (when using Chrome)

It turns out that I wasn't the only one infuriated by the default behavior of Google Calendar to scroll between months with a mouse wheel. Especially with the Apple Magic Mouse (which controls 2-dimensional scrolling with the touch-sensing top surface of the mouse), unintended switching between months is frequent and aggravating.

Programmer Ivan Morgillo created an extension for the Chrome browser which disables mouse scrolling in Google Calendar. The extension is open-source and free.

NOTE: After installing the extension, you'll need to quit and re-launch Chrome for the extension to disable mouse scrolling in Google Calendar.

Google Calendar Scroll Disabler at the Chrome Store

For nerds: google-calendar-scroll-disabler's GitHub page

HINT: If you want this behavior to be modified across all your Chrome-equipped computers, you can sync your extensions across Chrome installations.

Saturday, June 10, 2017

Google Assistant Shopping Lists moved from Google Keep to Google Home app

If you have been wondering why items added to your Google Assistant shopping list via Google Home weren't appearing in Google Keep, you (like me) missed this change by Google in April 2017.

Google Assistant's shopping lists are moving to the Home app today (The Verge)
While it's still great to be able to yell out additions to the shopping list from anywhere in the house (frankly, the single most promising task so far of being able to have speech-recognition in the home), I miss the organizational features of dedicated shopping list apps (my favorite being AnyList, which like Google Home's Shopping List, features the ability to collaboratively manage your list with other people). But for now, we'll keep working with Google Home, hoping for future improvements.

Friday, October 09, 2015

LED Torchiere Conversion

Twenty-three years ago, my wife and I moved into an apartment with very little built-in lighting, and purchased a couple of torchiere floor lamps to put in the living room and office. Their 300 watt quartz-halogen lamps provided a powerful, white light when turned up, and could be dimmed to a warm glow for quieter evening settings.

Twenty years ago, we moved into the house we now own, and placed the two torchieres in the living room, making for nice, soft indirect lighting on either side of our two chairs.

Perhaps 15 years ago, we picked up a couple of wall-mounted Quartz-halogen projector lamps in the "as-is" section of the Burbank IKEA. I mounted these as reading lights on the shaft of the torchieres (one for each of us), removing the torchieres' failing internal dimmers and routing the reading lights' wires through the now-available dimmer control opening and down through the core of the torchieres' poles to their DC power "bricks." I added external, remote-controlled AC dimmers for the torchieres.

Some years after that, I mounted rear satellite speakers for a surround-sound audio system high on the poles of each of the torchieres flanking our seats, firing rearward and slightly inward to reflect off the wall behind. The speaker wires joined the AC wires feeding the torchiere lamps, and DC wires powering the reading lights.

I've been slowly converting our home lighting from incandescent to LED (and very thankful never to have been faced with the ugly colors of fluorescent lighting). I'd noodled solutions for replacing the two 300 watt torchiere bulbs with lower-power LEDs for more than a year, researching available LEDs and power supplies (I still wanted dimmable lighting, which is a bit more exotic for LED driving circuits). Of late, there have been an increasing number of BIG, postage stamp-sized LEDs which produce light output adequate to replace any household application. I'd almost committed to buying separate components and fabricating a heat-sink/cooling system, when I stopped to look more closely at a LED ceiling down-light conversion kit at Costco. After some thought, I bought the $27 kit, containing two fixtures promising "same output as 120 watt" incandescent reflector flood lights, and 1,250 lumens of light output from only 21.5 watts. Manufacturer quotes of output of the 300 watt Quartz lamps in our torchieres quote nearly 5,000 lumen output, however, that's omnidirectional - light radiates in all directions from the glowing filament. LEDs output most of their light perpendicular to a plane, which is exactly where I want the light going - up into the ceiling. So I thought I might get away with a lower rating to achieve similar light levels.

Once home, I removed the diffusing lens (just breaking it off, then discovering that I missed two screws to remove it reversibly, which turned out to be moot) screwed the medium-base bulb adapter (the familiar threaded light bulb mount for the U. S.) into a work light socket and fired one of the fixtures into the ceiling at the same height as the torchiere lamps. It wasn't bad - about the same output as one of our torchieres which has an old, darkened lamp which was probably putting out half as much light as it could. But it was disappointing next to a freshly-relamped instrument.

I considered just going with the reduced light level, but then decided that I might be able to Siamese the two LED fixtures by sawing about 1/4 of each of their housings off. They would both then fit (sort of) within the upturned shade of the torchiere after I surgically removed all the original socket and reflector parts.

Further exploration and experimentation revealed that I could free the array of 18 LEDs and the steel disk to which they are bonded - I realized it wasn't glued as I first suspected, but merely stuck by silicone heat sink grease. The hockey puck-sized dimmable power supply was easily separated, though I had only about 1/3" of wire with which to solder on four connections between the power supplies and LEDs.

A couple of hours wandering around Home Depot yielded some galvanized steel plates (made for joining construction lumber), pop rivets, some threaded rod and a Plan.

I riveted the LED arrays from both of the fixtures on my fabricated mounting plates/heat sinks (with yet more heat sink grease), and tucked the power supplies underneath. The whole assembly floats above the torchieres' shallow, upturned bowl-shaped shades on two threaded rods.

Before (dimmed very low for photo)

After (also dimmed low)

When I fired it up, I was thrilled to find that the combined output of the 43 watts of LEDs equals or exceeds that of the brand new 300 watt quartz-halogen bulb, and the pattern on the ceiling and walls is perfect. The lights dim as hoped, though there is little to no color change (having warm colored lighting at night may be a better idea to prevent unwanted wakefulness), and the light levels abruptly change at some points - which matters not. Power consumption will drop to 1/7th of the original, and in the summer, the air conditioner will have to contend with over 500 fewer watts of heat in the living room at night.

The original halogen light on the left, and the LED on the right - the dimmers are set at only about 30 per cent, but the LED exhibits none of the reddish color change of a filament bulb.

Success! Our 20th-Century lamps are now 21st, and will continue to serve as reading lights and Surround Sound satellites for years to come.

Attending the 2015 AltCar Expo

My wife and I have attended several of the annual meetings of the AltCar Expo in Santa Monica, California.

Here are some comments I wrote for my old friends who are gear-heads.

Attending the 2015 AltCar Expo

Friday, June 19, 2015

The 2015 DARPA Robotics Challenge Finals - What Was It?

On June 5th and 6th, 2015, the Finals of the DARPA Robots Challenge were held at the Pomona Fairplex in Pomona, California. This was the culmination a three-year competition in which international teams developed hardware and software to complete a series of human-world tasks in a disaster/rescue environment. Organized and funded by the United States’ Defense Advanced Research Projects Agency, the competition was inspired by the aftermath of the 2011 Fukishima Daiichi nuclear powerplant disaster, and was intended to spur development of tools to aid in crisis events which present high-risk to humans. (When existing robots were deployed and utilized to evaluate the extremely dangerous areas of Daiichi site, it became evident that many critically-useful tasks could not be performed by existing robots.)

In previous years, DARPA held the DARPA Grand Challenge and the DARPA Urban Challenge, which pitted competitors against each other and against off- and on-road obstacle courses with motorized vehicles (which were mostly modified existing motor vehicles originally built for humans).

We attended the last day of the Robotics Challenge Finals, and what we witnessed was surprising and impressive, if not for obvious reasons.

Admission to the event was free. Trying to manage our time, we spent little time perusing the impressive amount of static exhibits laid out on the tarmac outside the Fairplex’s horse-racing stadium. Once we saw what was actually happening inside the stadium, we chose to prioritize watching the active competition.

I think it was better than I was relatively unprepared about the event. I’d only very briefly skimmed some documentation about the event - enough to know that a parameter of the competition was “intermittent periods of wireless connectivity” between the human controllers and the robots. This was meant to represent real-world conditions in which robots on disaster site might lose communications contact because of structural impedance or because of radio-frequency interference from rescue operations or equipment malfunctions.

I think my wife Joni and I were both surprised at the scale of the presentation, and the polish of the event. It was extremely well produced. Crowds were well-managed. The event’s graphics were well-placed and informative. Extremely elaborate multi-camera video and professional announcing and field reporting work provided a polished video feed to attendees and Internet viewers. Food and facilities (an easy call for the Pomona Fairplex, which hosts many large events annually, including the month-long, 1.5M visitor Los Angeles County Fair) were very good. I remind you that this was an exhibition of the Defense Advanced Research Projects Agency, the part of the United States military complex which a half-century ago created the embryo of what would become the Internet, and also any number of known and unknown defensive and offensive military technology projects. It’s a government project, and that’s not often a recipe for a Good Time.

In the huge covered grandstands at the Fairplex’ horse-racing track, we found seats in the bleachers, and took in the setting: In front of a crowd of a couple of thousand spectators, five stages were constructed. Flanking a center stage for human presentations, four identical three-walled “sets” were constructed (with an open side theatrically facing the audience) as obstacle courses. The robots were presented with eight tasks working in an environment with human ergonomics, and could score a single point for each challenge for a maximum of eight points. The total time required to finish the (optional) number of tasks they chose to complete was recorded. Final places were based upon total points achieved and lowest time required, and the top three finishing place teams were awarded $2 million, $1 million, and $500 thousand respectively. It should be noted that (as with the previous Grand and Urban Challenges) the costs of developing, purchasing and constructing the robots for several of the teams exceeded the the $2M first-place prize (I think I heard a $1M price tag quoted for one of the 3rd-party robots used by several teams), so for many teams, prize money was not a goal in and of itself. As with previous DARPA Challenges, teams were created and sponsored by commercial industry, government agencies, and educational institutions. Expense, creativity and innovation varied accordingly. The twenty-three teams featured competitors from six countries: Japan, Germany, Italy, Republic of Korea, China and the United States.

Multiple tracks defined teams which received some or no funding from DARPA.

Different from previous DARPA Challenges, teams were not required to design their own robots. Several teams chose to acquire existing robots from other enterprises, and modified or designed their own software for autonomous and human control. Among the 3rd-party robots purchased by teams, the most visibly recognizable were the six Atlas robots from Boston Dynamics. Many readers will know Boston Dynamics from YouTube videos of their “Big Dog” quadrupedal walking robot. (Boston Dynamics was purchased by Google in December 2013.) Another popular choice for teams not developing their own robots was the Robotis Thormang.

During the 2013 DRC Trials, robots were allowed to be mechanically tethered to protect them against damage during a fall, and were allowed to use an umbilical cable to provide external power and data connection. For these Finals, robots were disallowed from either of those aids. They would have to carry all the power required to operate for the 60 minute maximum task period onboard, and would have no safety system in the event of a fall (the final Task is a climb of 4 steps, and some of these mostly top-heavy robots weigh in excess of 180 kg/396 lbs, so they can really do themselves some damage). Most, but not all of the robots are bipedal walking robots, primarily because of the assumption that they would be the best solution for navigating in spaces and over obstacles designed for human beings. There are notable exceptions, like Team Aero’s Aero DRC, with four legs which also have wheels, and NASA Jet Propulsion Labs’ aptly-named RoboSimian, which contorts its four long multi-jointed appendages not unlike a tree-dwelling monkey to whatever configuration is appropriate for completing the current task safely.

Highlights from the 2013 DARPA Robotics Challenge Trials, showing safety-tethered and umbilical-connected robots attempting tasks.
Perhaps the most challenging change between the 2013 Trials and the Finals regards remote control and autonomy. For the Trials, robots could be constantly controlled by a physical data connection - wires. In the Finals, not only would all communications between teams and robot be wirelessly communicated, but the communication links would be deliberately degraded intermittently by DARPA organizers to simulate real-world communications problems at rescue sites. To this end, the expectation was that teams would develop software running internally within the robots that allowed them to complete the competition tasks without constant human help. According to DARPA video team interviews, teams typically “drive” robots to the task area and then initiate an autonomous routine to complete the task. Using multiple camera vision and laser 3-dimensional scanners, the robots would have to identify targets: a doorway, a door handle, a valve wheel, handheld power tools, stair steps, a shape on a plywood wall to be cut around - and manipulate the items in their environment to complete the current task. I think that had teams opted NOT to develop autonomous software, they might still be able to attempt every task manually. But because they wouldn’t know when and for how long DARPA organizers would interrupt their communications connection, their hopes of either achieving competitive times or even completing the stage within the maximum 60 minute time were unlikely.

I’m not certain, but I believe that the human team members were only able to use their robots’ sensing mechanisms to make control decisions from their command centers. So even if they chose to manually perform some tasks, they depended upon having designed adequate sensing infrastructure to apprehend the robot’s environment. So if they had only supplied their robot with a single camera view, it might prove difficult to guide a manipulator with no reference as to depth. We saw brief glimpses of 3-dimensional visualizations of objects on team computer monitors which reveals the nature of the robots’ “vision” systems. Most, if not all of the robots use LIDAR laser scanning systems (often visible as spinning devices mounted high on the robot) to provide their robots with a 3-dimensional model of both its environment and itself - robots must “look” at their own manipulator arms and graspers to determine where they are relative to their environment. (Here’s is a sample of this footage in the middle of a 4-hour DARPA video of the event.)

It should be noted that not all robots and teams attempted all tasks. Teams were allowed to choose to bypass some tasks, if the best use of their available resources with respect to the defined tasks was to skip a potential point-earning task in exchange for much lower elapsed total time. This might completely eliminate significant complexity in the design of the robot, and for those teams not expecting to place first, might improve their finishing positions by avoiding robot- or time-killing tasks. (It’s worth noting that the top three finishers were also the only teams to earn the maximum eight points.)

Teams were allowed to declare a “reset” on any given task, which (I think) earned them a 10-minute time penalty but allowed them to attempt the earn that point again.

The Tasks

  • Drive Task (1 point) -  the robot drives a utility vehicle over course of about 100 feet, with two traffic barriers creating a chicane about 2/3 of the way down the path. The robot is NOT responsible for getting into the vehicle - only to steer and operate the throttle pedal. Notably, several of the larger robots were “seated” in the passenger seat and operated the controls on the driver’s side - presumably because they would otherwise not clear the steering wheel. The track for this driving task ran the width of the fairground’s horse racing track, so the four competition courses covered a larger area than the simulated task rooms. This proved surprisingly difficult, and there were a lot of human team members pushing the vehicles back from interactions with barriers.

UNLV’s “Metal Rebel” completing the Drive Task successfully. 
(NOTE: You can view any of these videos full-screen by clicking on the button in the lower-right corner of the YouTube video windows.) 
  • Egress Task (1 point) - the robot must exit the vehicle and move about six feet away across a goal line. Teams were allowed to quickly modify the vehicles (without tools) to assist their robots in this task. Some extended simple structures out of the sides of the vehicles to serve as “handrails,” or other temporary stabilization points, and one team threw out a box on ropes to serve as a helper step for their walking robot (not all robots walked, some had wheels and tracked belts). This Task was particularly risky, and I heard a comment somewhere that teams didn’t appreciate the jeopardy that this Task presented to their robots early in the 60-minute completion window. Crashing here (and we saw some big crashes stepping out of vehicles) could prevent a team from earning more than the single Drive Task point.

Here’s Worchester Polytechnic Institute’s and Carnegie Mellon University’s joint entry “Warner” rehearsing Egress the week before the event. If this seems slow, know that some robots took 10-15 minutes to complete one task - most of which was standing in one place and “thinking.”
  • Door Task (1 point) - the robot must open the door (with a lever-style handle), push the door open, and walk across the threshold to gain 1 point. Sounds simple, but we witnessed several failures - including big “crashes” - right here. Many ‘bots stood at the doorway for several minutes, apparently assessing the position of the door and handle.

Team NEDO-JSK’s “Jaxon” earns a point by walking through a doorway. There’s nothing like hearing thousands of people cheer because someone walks through a doorway. (I’d accidentally written that as “walks through a door,” which might have been more than a typo at this event.)

Tartan Rescue’s “CHIMP” demonstrates that its unique design allows it to recover from a crisis in the Door Task which would have been a failure for many other designs.
  • Valve Task (1 point) - this task was specifically inspired by events in the wake of the Fukishima disaster. A wheel-type control valve handle must be rotated counterclockwise 360 degrees to earn a point. This is trickier than it sounds. When we do a task like this, we’re unconsciously shifting our weight on our feet to compensate for the forces we impart into the wheel.
UNLV’s Metal Rebel wins a point at the Valve Task.
  • Wall Task (1 point) - in this impressive challenge, robots select from any of four handheld (human) cordless cutting tools on a wall shelf (most robots knocked off at least one other tool during the task - which was not penalized). They then must completely cut a painted shape out of a section of drywall. All robots simply dropped the tool on the floor upon completion of the task, revealing that there was no specification for the final disposition of the tool. Most robots managed this pretty well. A few missed the painted target slightly, cutting slightly through the circumference of the black circle. But all that we saw managed to take a second cut and earn the point.

See NASA JPL’s RoboSimian make the cut to a cheering crowd in the Wall Task.
  • Surprise Task (1 point) - the “surprise” of this task is that DARPA didn’t inform teams what the task was until the day before the competition. However, I just found video of a team rehearsing what would be the Surprise Task back in March 2015, so I guess that suggests that it was a surprise choice from a known collection of tasks. The surprise task turned out to be unplugging an industrial electrical cord and plug from one outlet at “chest height,” and plugging into another. If we pulled a plug at this height, we would unconsciously have to shift our weight backward and forward to prevent from tipping as we pulled and pushed on the plug or cord. For some of the bipedal robots we watched, this tipping proved disastrous.

South Korean Team KAIST (who would go on to win the Finals and $2 million) practices the Plug Task months before the Finals.
  • Rubble Task (1 point) - to complete this task, the robot must either cross over an uneven arrangement of cinder blocks (these were meticulously identical on each of the four competition stages), or negotiate an alternate obstacle: an assortment of loose “debris” on a smooth floor. They were allowed to simply pick up the debris, but no robot we saw attempted that strategy. Notably, we saw one robot simply push its way through the debris (each piece of debris weighs less than 5 pounds) to cross the yellow line earning it the point for the task, though it did risk catching both ends of some long pieces, which might have prevented it from continuing to roll across the smooth floor.

Team IHMC Robotics “Running Man” attempts unsuccessfully to negotiate the Rubble Task.
  • Stairs Task (1 point) - for the last possible point-earning task, robots could climb four steps to a railed platform. There was a handrail on one side of the stairs. Strategies for climbing these stairs varied from the human-like approach of many frighteningly top-heavy bipedal designs to the monkey-like climb of NASA JPL’s RoboSimian. 

Team Tartan Rescue’s “CHIMP” uses the unique tracked belts on its four limbs to complete the final task for the maximum 8 points to win the $500K third-place prize.

Running Man” shows us all just how NOT to climb the stairs. Despite this fall and the Rubble Task fall on Day 1 of Finals, Team IHMC affected repairs overnight and to compete on Day 2 and finished in 2nd place overall.

A full description of the eight robot tasks is here on DARPA’s overview page for the Robotics Challenge Finals.

Our Takeaway

We were delightfully surprised at the efforts of the Defense Advanced Research Projects Agency to share this project with taxpayers. The event was well run, and the presentation was watchable and captivating. Watching robots slowly attempting each task was thrilling to watch - the sense of risk was not dissimilar to that of an Olympic athlete risking a lifetime of devoted practice and development, only to lose it all in a single fall. Hearing a crowd of people cheering and "Oh!"ing in unison at almost imperceptible accomplishments of these sometimes lifelike machines was unexpected, and added considerably to the experience.

Having watched online videos of the progress of walking robots over the past decade, we were still impressed at the state of the art - no doubt advanced by this competition. It wasn't so much about locomotion, but the apparently autonomous operations. Ironically, because of pauses which sometimes lasted several minutes, it was apparent that we were seeing software routines attempting to interpret the conditions of the environment with which the robots were presented. And the success rate of the competing robots shows how those teams rose to the occasion.

Will tomorrow's robots be better-suited at helping humans to perform perilous tasks in the near future? Most certainly. Moreover, it's easy for us to imagine that in the very near future, we might be seeing machines capable of adapting and reacting to their environment in ways that resemble living animals.

I'm looking forward to it.

More DARPA Robotics Challenge Finals Videos

Time lapse of the winning 44 minute, 28 second, 8-point run of Team KAIST’s “DRC-HUBO,” earning the Daejeon, South Korean team a $2 million prize.

Here is a time lapse video of TEAM IHMC Robotics “Running Man” completing their entire 50 minute, 21 second, 8-point run for a $1 million 2nd-place prize.
Here is DARPA’s YouTube channel, on which they have posted an 8 and half hour video of Day 1’s competition, and almost 9.5 hours of Day 2 (your Tax Dollars at work).

The video directors of the DARPA Robotics Challenge (which was being streamed live to the Internet, as well as to the five huge video displays behind the competition stages) played this hilarious blooper reel from the previous day’s competition even while the last dozen teams were agonizingly tending their robot’s last-ever competition day. It seemed a little cruel to those teams who had suffered these indignities, but I don’t blame the organizers for trying to make the event entertaining - the audience (and we) were in rapt attention during the challenge stages, and oohed, ahhed, gasped, laughed and applauded with more enthusiasm than they might have at many human-based events.
Boston Dynamics demonstrated a couple of their "Spot" quadrupeds - stunning