Dan Kohn’s Blog

I never knew how badly I needed a self-parking slipper until now!
By Evan Ackerman
from IEEE Specturm

Nissan, like every other car manufacturer that doesn’t want to be rendered mostly obsolete within the next few decades, has been gradually developing autonomous technology for its vehicles. They’ve been going about it very sensibly, introducing discrete modules like highway assist and parking assist, and they’ve managed to get the parking bit working well enough to take it beyond cars. One such attempt at an even more challenging and important self-parking application: slipper arrangements.

At first glance, the ProPILOT Park Ryokan looks like any other traditional Japanese inn, or ryokan. Slippers are neatly lined up at the foyer, where guests remove their shoes. Tatami rooms are furnished with low tables and floor cushions for sitting. What sets this ryokan apart is that the slippers, tables and cushions are rigged with a special version of Nissan’s ProPILOT Park autonomous parking technology. When not in use, they automatically return to their designated spots at the push of a button.

Even the television remote is self parking! Brilliant!

For its primary application, Nissan’s ProPILOT Park system uses an array of four cameras and twelve sonar sensors to wedge its host vehicle into even the smallest of parking spaces—whether it’s nose-in parking, butt-in parking, or trickiest of all, parallel parking. It seems unlikely that the slippers use quite the same technology, although Nissan does suggest that the technology is at least similar, which would mean that the slippers are operating autonomously rather than relying on someone off-camera with a remote control. If you’d like to investigate further, Nissan is offering a free night for a pair of travelers at this particular ryokan, which located in Hakone, Japan—a lovely place that you should consider visiting even if self-parking slippers aren’t on the amenities list.

Our only question now is, why limit this technology to cars, slippers, and pillows? I’d like my cereal bowls to be self parking. And my socks. And how about the toothpaste? Just think about how much more convenient it would be if all of these things were self-parking, too. So let’s get going with this, Nissan. Make our lives better already.

From: IEEE Spectrum
The 2017 Top Programming Languages
Python jumps to No. 1, and Swift enters the Top Ten
By Stephen Cass
Date: July 18, 2017

It’s summertime here at IEEE Spectrum, and that means it’s time for our fourth interactive ranking of the top programming languages. As with all attempts to rank the usage of different languages, we have to rely on various proxies for popularity. In our case, this means having data journalist Nick Diakopoulos mine and combine 12 metrics from 10 carefully chosen online sources to rank 48 languages. But where we really differ from other rankings is that our interactive allows you choose how those metrics are weighted when they are combined, letting you personalize the rankings to your needs.

We have a few preset weightings—a default setting that’s designed with the typical Spectrum reader in mind, as well as settings that emphasize emerging languages, what employers are looking for, and what’s hot in open source. You can also filter out industry sectors that don’t interest you or create a completely customized ranking and make a comparison with a previous year.

So what are the Top Ten Languages for the typical Spectrum reader?

[Click here to explore interactive rankings]

Python has continued its upward trajectory from last year and jumped two places to the No. 1 slot, though the top four—Python, C, Java, and C++—all remain very close in popularity. Indeed, in Diakopoulos’s analysis of what the underlying metrics have to say about the languages currently in demand by recruiting companies, C comes out ahead of Python by a good margin.

C# has reentered the top five, taking back the place it lost to R last year. Ruby has fallen all the way down to 12th position, but in doing so it has given Apple’s Swift the chance to join Google’s Go in the Top Ten. This is impressive, as Swift debuted on the rankings just two years ago. (Outside the Top Ten, Apple’s Objective-C mirrors the ascent of Swift, dropping down to 26th place.)

However, for the second year in a row, no new languages have entered the rankings. We seem to have entered a period of consolidation in coding as programmers digest the tools created to cater to the explosion of cloud, mobile, and big data applications.

Speaking of stabilized programming tools and languages, it’s worth noting Fortran’s continued presence right in the middle of the rankings (sitting still in 28th place), along with Lisp in 35th place and Cobol hanging in at 40th: Clearly even languages that are decades old can still have sustained levels of interest. (And although it just barely clears the threshold for inclusion in our rankings, I’m pleased to see that my personal favorite veteran language—Forth—is still there in 47th place).

Looking at the preset weighting option for open source projects, where we might expect a bias toward newer projects versus decades-old legacy systems, we see that HTML has entered the Top Ten there, rising from 11th place to 8th. (This is a great moment for us to reiterate our response to the complaint of some in years past of “HTML isn’t a programming language, it’s just markup.” At Spectrum, we have a very pragmatic view about what is, and isn’t, a recognizable programming language. HTML is used by coders to instruct computers to do things, so we include it. We don’t insist on, for example, Turing completeness as a threshold for inclusion—and to get really nitpicky, as user Jonny Lin pointed out last year, HTML has grown so complex that when combined with CSS, it is now Turing complete, albeit with a little prodding and requiring an appreciation of cellular automata.)

Finally, one last technical detail: We’ve made some tweaks under the hood to improve the robustness of the results, especially for less popular languages where the signals in the metrics are weaker and so more prone to statistical noise. So that users who look at historical data can make consistent comparisons, we’ve recalculated the previous year’s rankings with the new system. This could lead to some discrepancies between a language’s ranking in a given year as currently shown, versus the ranking that was shown in the original year of publication, but such differences should be relatively small and not affect the more popular languages in any case.

From IEEE Spectrum

By Evan Ackerman
Posted 29 Jun 2017 | 13:00 GMT

Last December, Duncan Haldane (whose research on incredibly agile bioinspired robots we’ve featured extensively in the past) ended up on the cover of the inaugural issue of Science Robotics with his jumping robot, Salto. Salto had impressive vertical jumping agility, and was able to jump from the ground onto a vertical surface, and then use that surface to change its direction with a second jump. It was very cool to watch, but the jumping was open-loop and planar, meaning that two jumps in a row was just about all that Salto could manage.

Haldane mentioned to us in December that future work on Salto could include chaining together multiple jumps, and in a paper just accepted to the 2017 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), he and co-author Justin Yim at UC Berkeley’s Biomimetic Millisystems Lab, led by Professor Ronald Fearing, show the improvements that they’ve made over the last six months. Thanks to some mechanical fine-tuning and the clever addition of a pair of thrusters, the new Salto-1P is jumping longer, faster, and higher than ever. Prepare to be amazed.

We’ve seen other jumping robots over the years, but Salto-1P takes the cake. Watch this:

Salto is short for “Saltatorial Locomotion on Terrain Obstacles,” a reference to saltatorial animals, which are adapted to locomotion by jumping. Kangaroos and rabbits are a few saltatorial animals that you’re probably familiar with, but Salto was particularly inspired by the galago, or bushbaby, which has a vertical jumping agility that no other animal can match. The galago is able to manage this thanks to a rather clever bit of leg design which uses variable mechanical advantage, leveraging the shape of their leg to amplify the force that their muscles can deliver. For all the details on the jumping ability of the original Salto (and how it’s different from other jumping robots), be sure and read our very in-depth article about it, because this article is focused on the new and upgraded Salto-1P.

The original Salto was able to control its pitch through the use of a rotating inertial tail: By spinning the tail one way, the robot could pitch itself in the other direction. This worked very well, but only in one plane, which made Salto difficult to control. Salto-1P is, according to Haldane, essentially “Salto with half of a mini-quadrotor glued to it.”

Those two little thrusters are able to control Salto-1P’s yaw and roll: When they’re thrusting in different directions, the robot yaws, and when they both thrust in the same direction, the robot rolls. Combined with the tail, that means Salto-1P (which only ways 98 grams) can stabilize and control itself in three dimensions, even in mid-air, which is what allows it to chain together so many jumps. Other hardware modifications include a deeper crouch than the original Salto, which allows more energy to be transferred from the jumping motor into the spring, giving it the highest vertical jumping agility of any battery powered robot at 1.83 m/s.

Haldane says one issue that came when they redesigned the leg mechanism to allow the robot to jump higher is that, as he puts it, “Salto lost its friendly and forgiving nature.” The robot would occasionally “fire pieces of itself across the room when the motor tore the leg-mechanism apart.” They had to do revise the design to keep everything in one piece. The video below is a compilation of Salto-1P’s “little acts of self-destruction”:

The software that Salto-1P is running to make all of this work is an adaptation of Marc Raibert’s hopping controller from 1984. Raibert’s 3D One-Leg Hopper weighed 170 times more than Salto-1P, and can’t jump nearly as high, but fundamentally the algorithm works just as well on Salto as it did on Raibert’s hopper more than 30 years ago. However, controlling Salto-1P involves some unique challenges, because the robot spends so little time on the ground. In fact, 92 percent of the time, the robot is in the air, which means that you really have to control it in the air, which is why the tail and thrusters are necessary (as opposed to control through the leg and foot).

This results in enormous accelerations (on the order of 14 g’s), and to put this in context, Haldane compares Salto-1P to a cheetah: The robot has “a lower duty cycle than a single cheetah limb at top speed,” he says, adding: “Imagine a cheetah running at top speed using only one leg, and then cut the amount of time that leg spends on the ground in half. That’s the duty factor of Salto-1P.”
“Imagine a cheetah running at top speed using only one leg, and then cut the amount of time that leg spends on the ground in half. That’s the duty factor of Salto-1P.” —Duncan Haldane, UC Berkeley

It’s important to note that when you see Salto-1P bouncing around in the video, it’s doing so untethered, but not completely autonomously: There’s a bunch of stuff going on in the background to get it to perform the way it does. The path it follows relies on motion capture, with an offboard computer (though not a particularly powerful one) receiving tracking data and wirelessly sending control commands to the robot.

“Motion capture is an easy way to track the robot that freed us up to work more on the robot mechanics,” co-author Justin Yim explains. “It’s also useful for gathering performance data since we can very closely track Salto-1P throughout its hopping.” It’s also worth noting that Salto-1P isn’t doing a lot of sensing on its own, and it’s still able to handle all those obstacles at the end of the video, which is impressive.

https://www.kickstarter.com/projects/871405126/turing-tumble-gaming-on-a-mechanical-computer

From: IEEE – The Institute

Grace Murray Hopper, 1906–1992

Known for: Inventing the computer compiler and leading the development of the programming language COBOL (common business-oriented language).

Why it matters: Hopper is considered one of the founders of the information age. Her compiler, a collection of coded instructions that could be reused, saved programmers from having to write each program anew. It significantly advanced the art of programming. By the late 1970s, COBOL was the most extensively used computer language in the world.

Where she started: Hopper was a mathematics professor at Vassar College, in Poughkeepsie, N.Y., when she joined the U.S. Navy Waves (women accepted for voluntary service) program in December 1943. She was commissioned a lieutenant the following year. She was named an IEEE Fellow in 1962 “for contributions in the field of automatic programming.”

Breakthrough: As a Navy lieutenant, she was assigned in 1944 to program the Mark I Automatic Sequence Controlled Calculator at Harvard under Howard Aiken, a computing pioneer. The Mark 1, one of the first programmable computers, is an IEEE Milestone.

http://spectrum.ieee.org/view-from-the-valley/robotics/industrial-robots/sri-shakey-robot-honored-as-ieee-milestone/?utm_source=RoboticsNews&utm_medium=Newsletter&utm_campaign=RN02282017

http://spectrum.ieee.org/automaton/robotics/humanoids/boston-dynamics-handle-robot/?utm_source=RoboticsNews&utm_medium=Newsletter&utm_campaign=RN02282017

From: IEEE Spectrum

Click HERE for full story.

Let’s Bring Rosie Home: 5 Challenges We Need to Solve for Home Robots
From IEEE Spectrum
By Shahin Farshchi
Posted 13 Jan 2016 | 16:25 GMT

Science fiction authors love the robot sidekick. R2-D2, Commander Data, and KITT—just to name a few—defined “Star Wars,” “Star Trek,” and “Knight Rider,” respectively, just as much as their human actors. While science has brought us many of the inventions dreamed of in sci-fi shows, one major human activity has remained low tech and a huge source of frustration: household chores. Why can’t we have more robots helping us with our domestic tasks? That’s a question that many roboticists and investors (myself included) have long been asking ourselves. Recently, we’ve seen some promising developments in the home robotics space, including Jibo’s successful financing and SoftBank’s introduction of Pepper. Still, a capable, affordable robotic helper—like Rosie, the robot maid from “The Jetsons”—remains a big technical and commercial challenge. Should robot makers focus on designs that are extensions of our smartphones (as Jibo seems to be doing), or do we need a clean-sheet approach towards building these elusive bots?

Take a look at the machines in your home. If you remove the bells and whistles, home automation hasn’t dramatically changed since the post–World War II era. Appliances, such as washing machines, dishwashers, and air conditioners, seemed magical after WWII. Comprised primarily of pumps, motors, and plumbing, they were simply extensions of innovations that came to bear during the industrial revolution. It probably doesn’t come as a surprise that industrial behemoths such as GE, Westinghouse, and AEG (now Electrolux) shepherded miniature versions of the machines used in factories into suburban homes. At the time, putting dirty clothes and dishes into a box from which they emerged clean was rather remarkable. To this day, the fundamental experience remains the same, with improvements revolving around reliability, and efficiency. Features enabled by Internet-of-Things technologies are marginal at best, i.e., being able to log into your refrigerator or thermostat through your phone.

But before wondering when we’ll have home robots, it might be fair to ask: Do we even need them? Consider what you can already do just by tapping on your phone, thanks to a host of on-demand service startups. Instacart brings home the groceries; Handy and Super send professionals to fix or clean your home; Pager brings primary care, while HomeTeam does elderly care. (Disclosure: my company, Lux Capital, is an investor in Super, Pager, and HomeTeam.) So, again, why do we need robots to perform these services when humans seem to be doing them just fine? I don’t think anyone has a compelling answer to that question today, and home robots will probably evolve and transform themselves over and over until they find their way into our homes. Indeed, it took decades of automobiles until the Model T was born. The Apple IIs and PC clones of the early 1980s had difficulty justifying their lofty price tags to anyone who wasn’t wealthy, or a programmer. We need to expect the same from our first home bots.

So it might be helpful to examine what problems engineers need to crack before they can attempt to build something like Rosie the robot. Below I discuss five areas that I believe need significant advances if we want to move the whole home robot field forward.

1. We Need Machine-Human Interfaces

Siri and Amazon’s Alexa demonstrate how far speech recognition and natural language processing have come. Unfortunately, they are no more than a human-machine interface, designed to displace the keyboard and mouse. What we need is a machine-human interface. Where is the distinction? It starts with understanding people, rather than aggregating data and using statistical patterns to make inferences. It can understand our moods and emotional contexts, as an artificial intelligence would. Humans do not interact with one another through a series of commands (well, maybe some do); they establish a connection, and once a computer can take on that role, then we have a true machine-human interface. Scientists are starting to tackle this by applying concepts used in programming toward establishing rules for robot-human conversations, but we’ll need much more if we want to have engaging AI assistants like the one in the movie “Her.” ​

2. Cheap Sensors Need to Get Cheaper

Driverless cars will generate hard cash for their operators, so forking over thousands for an array of lidar, radar, ultrasound, and cameras is a no-brainer. Home robots, however, may need to fit the ever-discretionary consumer budget. The array of sensors the robot would need to properly perceive its environment could render it cost prohibitive unless the sensors cost pennies as they do in mobile phones. MEMS technology dramatically lowered the cost of inertial sensors, which previously cost thousands of dollars and were relegated to aircraft and spacecraft. Can computer vision applied to an array of cheap cameras and infrared sensors provide adequate sensing capability? And can we expect lidar to come down in price, or do we need a whole new sensing technology? A startup called Dual Aperture has added a second aperture for infrared hence creating the ability to infer short distances. Meanwhile, DARPA is funding the research on chip-based lidar, and Quanergy expects to launch a solid-state optical phased array, thereby eliminating the mechanical components that raise the cost of lidar. We expect engineers to find creative ways to reduce the cost of existing sensing technology, while obviating others altogether, and hopefully making them as cheap as sensors in our phones today.

3. Manipulators Need to Get a Grip

Loose objects find their way into our homes because they are easy to manipulate with our hands. If we expect a robot to be able to clean and organize these objects as efficiently as humans do, it needs manipulators that are at least as effective as the human hand. Companies such as Robotiq, Right Hand Robotics, and Soft Robotics, among others, have designed efficient and reliable manipulators. Though air-powered inflatable grippers have the advantage of being soft and lightweight, they do require a pump, which is not very practical for a mobile robot. Efforts funded by DARPA at iRobot, SRI, and other labs and companies seem to be taking us in the right direction, helping robots get a grip.

4. Robots Need to Handle Arbitrary Objects

Opening doors, flipping switches, and cleaning up scattered toys are simple tasks for us humans, but compute-intense for machines today. A robot like Roomba performs two tasks: running a suction motor and generating a path along what’s expected to be a flat surface with rigid obstacles. How about washing dishes or folding laundry? These tasks require a suite of capabilities ranging from recognizing objects, identifying grasping points, understanding how an object will interact with other objects, and even predicting the consequences of being wrong. DARPA, NSF, NASA, and European Union science funding agencies are sponsoring much-needed research in this area, but “solving manipulation” will probably require leveraging a number of different technologies, including cloud robotics and deep learning.

5. Navigating Unstructured Environments Needs to Become Routine

Anyone who saw this year’s DARPA Robotics Challenge would appreciate how difficult of a problem it is to navigate and manipulate an unstructured, unknown environment. Those robots were slow. Though driverless cars pose a formidable challenge, it has been proven to be more tractable. Deep learning techniques can help robots recognize soft objects vs. hard obstructions, and human assistants may be able to “teach” robots until the algorithms take over. Like the manipulation problem, real-time navigation requires robots to quickly sense, perceive, and execute—probably several orders of magnitude faster that they DRC winning team is today. Full autonomy won’t happen overnight, but that isn’t a problem: humans can help robots get out of a bind. Willow Garage was a pioneer with its Heaphy Project, where assistance to robots is crowdsourced to remote operators. More robotics and industrial automation companies are embracing the notion of humans overseeing robots, with the expectation of going from the (superfluous) 1:1 human-robot ratio to a single operator being able to oversee/assist many robots.

Shahin Farshchi is a partner at Lux Capital, where he invests in hardware and robotics companies. Follow him on Twitter:@farshchi

From IEEE Spectrum

Click here for the full story.