Talking to Robots: Learning to Ground Human
Language in Robotic Perception

Cynthia Matuszek
University of Washington

1:00pm Monday, 7 April 2014, ITE325b, UMBC

Advances in computation, sensing, and hardware are enabling robots to perform an increasing variety of tasks in ever less constrained settings. It is now possible to imagine robots that can operate in traditionally human-centric settings. However, such robots need the flexibility to take instructions and learn about tasks from nonspecialists using language and other natural modalities. At the same time, learning to process natural language about the physical world is difficult without a robot’s sensors and actuators. Combining these areas to create useful robotic systems is a fundamentally multidisciplinary problem, requiring advances in natural language processing, machine learning, robotics, and human-robot interaction. In this talk, I describe my work on learning natural language from end users in a physical context; such language allows a person to communicate their needs in a natural, unscripted way. I demonstrate that this approach can enable a robot to follow directions, learn about novel objects in the world, and perform simple tasks such as navigating an unfamiliar map or putting away objects.

Cynthia Matuszek is a Ph.D. candidate in the University of Washington Computer Science and Engineering department, where she is a member of both the Robotics and State Estimation lab and the Language, Interaction, and Learning group. She earned a B.S. in Computer Science from the University of Texas at Austin, and M.Sc. from the University of Washington. She is published in the areas of artificial intelligence, robotics, ubiquitous computing, and human-robot interaction.

Talking to Robots: Learning to Ground Human
Language in Robotic Perception

Cynthia Matuszek
University of Washington

1:00pm Monday, 7 April 2014, ITE325b, UMBC

Advances in computation, sensing, and hardware are enabling robots to perform an increasing variety of tasks in ever less constrained settings. It is now possible to imagine robots that can operate in traditionally human-centric settings. However, such robots need the flexibility to take instructions and learn about tasks from nonspecialists using language and other natural modalities. At the same time, learning to process natural language about the physical world is difficult without a robot’s sensors and actuators. Combining these areas to create useful robotic systems is a fundamentally multidisciplinary problem, requiring advances in natural language processing, machine learning, robotics, and human-robot interaction. In this talk, I describe my work on learning natural language from end users in a physical context; such language allows a person to communicate their needs in a natural, unscripted way. I demonstrate that this approach can enable a robot to follow directions, learn about novel objects in the world, and perform simple tasks such as navigating an unfamiliar map or putting away objects.

Cynthia Matuszek is a Ph.D. candidate in the University of Washington Computer Science and Engineering department, where she is a member of both the Robotics and State Estimation lab and the Language, Interaction, and Learning group. She earned a B.S. in Computer Science from the University of Texas at Austin, and M.Sc. from the University of Washington. She is published in the areas of artificial intelligence, robotics, ubiquitous computing, and human-robot interaction.

What is good code?

We know when we spot bad code. But because good programming is harder to define, it’s difficult to know you’ve actually created quality.

In my experience, there are two great questions that can indicate code quality:

• When you’re working on a team, do others easily understand your code’s logic?
• When changes are required, is it a quick and straightforward process?

If it’s difficult to explain code to others or if lots of things break when making changes, then chances are the code is bad. Fixing these problems often involves finding sensitive solutions in the context of a particular environment. For example, perhaps it’s a matter of using an established design pattern, or writing unit tests.

While it’s important to fix code directly, it’s equally important to address the conditions that lead to bad code in the first place. Every time I’ve encountered poor programming on a project I’m working on, it has typically stemmed from the same chronic issues.

Don’t optimize code too soon

When I first started programming, I remember marveling at my own “brilliance” when I was able to condense several lines of code into a single line. I would remove all the spaces and comments I made, nest multiple function calls instead of using clearly marked variables, and so on. I would also look for any type of optimization I could find, no matter how small.

Like building an engine, fine-tuning every last detail of your code will only make you feel like a genius temporarily, and usually the increased performance is marginal. (Photo from Flickr user Andrew Taylor.)

Writing clear code is more important that writing clever code. I once learned this when I had to go back and modify one of my own projects after letting it sit for six months. By that point, I had to spend a lot of time just figuring out what I wrote before I could make the necessary change. Suddenly, I didn’t feel so clever.

Never hack a framework

All developers encounter high-pressure deadlines from time to time. Maybe you’re preparing the latest version of a project for client review or for a public demo. The clock is ticking and there’s code to deliver, so you start taking shortcuts. Sometimes these are necessary and can indeed be refactored later, as long it’s done “the right way” soon after.

However, hacking a framework like Bootstrap or jQuery is never a shortcut. Sure, it might help get something delivered quickly, but ultimately these end up being expensive to fix. In the worst-case scenarios, the client might be promised functionality that’s only possible by making changes to framework files rather than properly building proper code. Those unusual hacks must to be maintained going forward.

Refactor every so often

Speaking of shortcuts, it’s a good idea to collect all those quick-and-dirty hacks into one place using a shame.css file. (The same idea can be applied to non-web projects.) Then when the high-pressure delivery date has lapsed, it’s easy to erase all the “shame” and rewrite the code properly. Even when I’m not making quick hacks, I still try to allow myself time to review, reflect, and refactor. For example, when you revisit some of the first code you wrote, is it still easy to understand? As a project grows, this becomes increasingly important.

I also recommend doing this in the morning or after the weekend. The passage of time always provides a fresh perspective, and it’s a good way to get back into a workflow.

Use revision control for your code

If you’re not using revision control, you should start today. Github is free and reasonably priced if your needs grow. Coding without revision control is like driving without a seatbelt. Everything will be fine for a while, but as soon as something goes wrong, the consequences can be dire.

I’ve worked on several projects that involved “cowboy coding” with total disregard for simple precautions, and in every case, a revision control system could have made work move a lot faster. If you need to learn how to use a revision control system like git, check out the Git Basics course on Treehouse. Here’s the trailer:

Allow time for learning

When you’re crunching between one deadline and the next, learning can feel like a luxury. A programmer who isn’t learning, however, is just treading water. Almost every time I learn something new, it helps me work faster and more efficiently. This can immediately elevate quality of life if it means career advancement or more leisure time. What always amazes me is the ratio between the time it takes to learn something new versus the time that it ultimately saves. Try to learn something every day and, over time, you’ll reach a new level of understanding.

If you have more tips you’d like to share, I’d love to hear them in the comments!

The post Tips for Writing Better Code appeared first on Treehouse Blog.

If the NSA did have the keys to the backdoor in a random number generator it could break some encryption without trouble.

The security of a data connection protected using a flawed U.S. encryption standard promoted by the National Security Agency could be broken in under 16 seconds using a single computer processor. That’s according to the first in-depth study of how easily encryption systems that use the now deprecated Dual_EC random number generator could be defeated by an attacker that had “backdoored” the standard.