Tuesday, November 1, 2016
Monday, October 24, 2016
I learned how to write after defending my phD
Everything I learned about writing research papers I learned after 11 years of higher education, and more importantly, after the 205 pages and 55 minutes of my Ph.D Thesis Defense. For the first time in my academic life, four accomplished researchers reviewed my enormous thesis document, and provided incredibly useful feedback about academic writing style and experimental structure in typical academic research paper.
Typically, academic writing is a sink or swim affair. If you have a really good advisor, they might actually read your work, and even provide feedback about your papers. But in terms of numbers, the bulk of the feedback budding academic computer scientists get about how to present their work comes from (usually) rejected conference papers. The peer review process means that there will be 2-4 anonymous researchers who read you eight page double-column formatted paper and critique your paper. Academics have big egos, particularly about research ideas, so on first read, this paper reviews can feel very much like reading a Youtube comment thread -- in other words, soul-crushing and depressing.
Over the years, I, like probably many academics, have developed a technique for dealing with the post-review-reading depression, that usually involves going drinking with friends and letting the contents of the reviews sit for 24 hours before trying to find the good ideas within the criticism. It's a great life skill, say some. It's helped me develop a thick skin, say others. I assume both of these perspectives also involve crying on the inside. The worst is when the comments make it clear that the reviewer has only read your abstract and not the contents of the paper, because then you feel righteous, but even the accepted papers with be sprinkled with these kinds of things.
In the end, it is important to be humble. The reader is never wrong, as my PhD advisor said. If I were to have written more clearly there would have been fewer misunderstandings, and perhaps they would have chosen to dig deeper into the paper. And now that I review more papers than I submit (11 sitting on my desk at the moment, metaphorically speaking, relative to the two I submitted in September), I can see things from both sides.
But one thing that is clear is the average rising academic is woefully unprepared about the process of writing. I found it fascinating that at the point that I already had secured an assistant professorship, that I had already written (the original draft) and orally presented my dissertation, that THAT was the point at which my mentors acknowledged that I was truly committed to this process and took the time to review the secrets behind the curtain that had, in some ways, been eluding me for so many years. In my next post, I will present their wisdom...
Typically, academic writing is a sink or swim affair. If you have a really good advisor, they might actually read your work, and even provide feedback about your papers. But in terms of numbers, the bulk of the feedback budding academic computer scientists get about how to present their work comes from (usually) rejected conference papers. The peer review process means that there will be 2-4 anonymous researchers who read you eight page double-column formatted paper and critique your paper. Academics have big egos, particularly about research ideas, so on first read, this paper reviews can feel very much like reading a Youtube comment thread -- in other words, soul-crushing and depressing.
Over the years, I, like probably many academics, have developed a technique for dealing with the post-review-reading depression, that usually involves going drinking with friends and letting the contents of the reviews sit for 24 hours before trying to find the good ideas within the criticism. It's a great life skill, say some. It's helped me develop a thick skin, say others. I assume both of these perspectives also involve crying on the inside. The worst is when the comments make it clear that the reviewer has only read your abstract and not the contents of the paper, because then you feel righteous, but even the accepted papers with be sprinkled with these kinds of things.
In the end, it is important to be humble. The reader is never wrong, as my PhD advisor said. If I were to have written more clearly there would have been fewer misunderstandings, and perhaps they would have chosen to dig deeper into the paper. And now that I review more papers than I submit (11 sitting on my desk at the moment, metaphorically speaking, relative to the two I submitted in September), I can see things from both sides.
But one thing that is clear is the average rising academic is woefully unprepared about the process of writing. I found it fascinating that at the point that I already had secured an assistant professorship, that I had already written (the original draft) and orally presented my dissertation, that THAT was the point at which my mentors acknowledged that I was truly committed to this process and took the time to review the secrets behind the curtain that had, in some ways, been eluding me for so many years. In my next post, I will present their wisdom...
Saturday, March 12, 2016
Programmer’s Block
[Book concept] There are many books on writing, economically written, that could be cross-applied to the struggles of a programmer in ‘writing’ code. There are just as many programmers that struggle with the creative and mental challenges of software development as in writing, but there do not exist similarly accessible guides. Instead, the software development literature focuses on skills, instead of questions of psychology, motivation and style.
It is common to characterize programming as problem-solving rather than a creative process. But in truth, especially if you work in a field like I do, it’s both. (Writing is both too.) In my own work as a social roboticist, I have often struggled with Programmer’s Block. I have concepts that need to translate to lines of code in ways that I struggle to articulate.
I make human-inspired algorithms for robots, simplified social behaviors that a person can automatically interpret the way we interpret each other. In this sense, I am programming “living” characters. A mother and father may provide the basic DNA, however, who a child becomes involves many more variables. The motivations and expressions and ability to parse the people around it present formations of impressions of character are nondeterministic, but that I hope to influence in statically predictable ways.
Programming is Thinking
Much like modern engineers do more than solve problems their boss hands them (they come up with ideas, start companies, create art), programming has become more than a set of skills, it is a way to explore interactivity. One of my favorite phrases from the writing books is “Writing is Thinking” — it’s hard to see the faults and strengths in your logic into you spill it from your head onto the page. Programming is the same way, the big concept you start with turns out to have twists and turns, each of which needs to be defined. Programming is thinking provides explicit feedback, sometimes fatal errors, other times warnings again to the green and red underlines that auto-check your grammar and spelling.
Cultivate a Programming Addiction
Daily practice, small problems, goals that are impossibly to miss. Happiness is not drinking beer, kicking your feet up, it's Flow.
Conceptualizing vs. Editing
Use different materials, look at thinks from different angles.
Elements of Style (in Python)
We adopt coding conventions to make our code readable to others, but also because it becomes
It is common to characterize programming as problem-solving rather than a creative process. But in truth, especially if you work in a field like I do, it’s both. (Writing is both too.) In my own work as a social roboticist, I have often struggled with Programmer’s Block. I have concepts that need to translate to lines of code in ways that I struggle to articulate.
I make human-inspired algorithms for robots, simplified social behaviors that a person can automatically interpret the way we interpret each other. In this sense, I am programming “living” characters. A mother and father may provide the basic DNA, however, who a child becomes involves many more variables. The motivations and expressions and ability to parse the people around it present formations of impressions of character are nondeterministic, but that I hope to influence in statically predictable ways.
Programming is Thinking
Much like modern engineers do more than solve problems their boss hands them (they come up with ideas, start companies, create art), programming has become more than a set of skills, it is a way to explore interactivity. One of my favorite phrases from the writing books is “Writing is Thinking” — it’s hard to see the faults and strengths in your logic into you spill it from your head onto the page. Programming is the same way, the big concept you start with turns out to have twists and turns, each of which needs to be defined. Programming is thinking provides explicit feedback, sometimes fatal errors, other times warnings again to the green and red underlines that auto-check your grammar and spelling.
Cultivate a Programming Addiction
Daily practice, small problems, goals that are impossibly to miss. Happiness is not drinking beer, kicking your feet up, it's Flow.
Conceptualizing vs. Editing
Use different materials, look at thinks from different angles.
Elements of Style (in Python)
We adopt coding conventions to make our code readable to others, but also because it becomes
Wednesday, March 9, 2016
Laban Framework Journal Paper
Laban Design Framework Big Ideas
(Thanks Matt from GCC)
---
BACKGROUND
Robots are finding increasing numbers of applications in human environments, where they benefit from communicating with people. The goal of this paper is to explore expressive motion, a subtype of robot body language that people automatically read and interpret because of its cognates to how we communicate with each other.
This is increasingly relevant at a time where industry is investing in collaborative robots on the factory line, where human operators help coordinate the robot's tasks. The operators often work out of visual range of the robot, bringing it supplies or picking up parts that it has completed, as necessary, e.g., at 20 minute intervals.
For example, in a recent ethnographic study with the Baxter robot, researchers found:
SIGNIFICANCE
The advantages of Expressive Motion include more fluent coordination between people and machines and simplicity of hardware. The essential idea of our work is that the common robot form-factors of today, which are generally quite simple, can leverage expressive motion while getting things done.
The benefits of Expressive Motion are twofold:
Further, we see that people working with robots appreciate the non-verbal features included in the robot's face, but desire increased levels of social interaction. Expressive Motion is a useful channel to do that with, because it requires no new hardware and is visible from far away. Unlike Baxter's robot on-screen face, it requires no additional expense in hardware, but extends well to multi-modal communication. Motion is also a channel that applies to all robots.
APPROACH
Our approach is to layer these expressive motion on the task motions the robot is already performing. We do this by operationalizing a system from Dance and Theater training called the Laban Effort System, which identifies generalizable motion characteristics that could apply to any robot platform.
Layering: Most robots have motion features that they could vary while still accomplishing their task goals. An autonomous cars has a range of acceptable speeds that it can choose from on the highway, a variety of acceleration patterns that it could use to get up to those speeds and a range of acceptable distances it could maintain from the car in front of it.
Generalizable: The Laban Effort System provides qualitative rules of thumb for what aspects of those motion features influence people's perception of its current expressive state. These features would be equally applicable (after calibration) to autonomous cars, as to robotic vacuum cleaners or hospital delivery robots. Past work has shown that legible motion improves performance on the factory line. Our work would increase the variety of states a robot was capable of communicating through motion.
This approach contrasts with previous work, which, while showing expressive motion to be helpful, has often used animators to craft individual motion sequences (not scalable) or inserted gestures into the robot's motion sequence that could interrupt its functional motions.
AUDIENCE
We will share our approach and experimental results, and hope they will prove useful and applicable to other researchers. We acknowledge that there are other ways to use parameterized motion features, and welcome you to pick and choose what parts work for you, refining the particulars to your application setting or research.
By way of illustration, I can think of two audiences for whom this work could be useful. On the one end of the spectrum are the designers. For example, recent work on roboticized furniture establishes that people can read abstracted motion patterns, for example, a robotic ottoman inviting you to put up your feet (or get them down), or set of desk drawers opening in an energetic or lethargic way seeming to have varied levels of desire to help you. For a designer, a rounded knowledge of the space of Laban Effort features could open up hand-crafted explorations to motion features you had not previously considered. These features build on the expertise of dance and acting experts that has been leveraged and case-tested for over seventy years.
On the other end of the spectrum are roboticists working in manipulation that find the idea of expression interesting, but also need to optimize over many other task considerations (path length, collision likelihood, grasp success probability). Algorithms people want the expressive content of a particular robot path instance, e.g., 'urgency,' to reduce to a single number that they can then use to evaluate the hundreds of proposed path samples their motion planner comes up with, before selecting the 'best' solution. Using this guide, you could follow a similar process of training 'urgency' features, but this time in a continuous fashion, such that you can establish a 0-1 scale rating how urgent particular motion features or Laban Effort Settings appear.
METHOD
So how do we incorporate Expressive Motion into a robot Task?
The first step is to identify the feature space available for motion expression. The constraints here include the robot's hardware limits (D.O.F.s) - you can't include an orientation feature if the robot doesn't orient; and software limits - you can't include acceleration features if the motor controller doesn't support acceleration. The motion feature constraints will also come from the robot's task; you can't use average speed features if the robot is already required to hit a beat at a particular rate, but you may be able to vary acceleration profile.
Within most robot tasks, there is an allowable range of motion features. For example, the CoBot robots (one of the central platforms for this project) navigate down office corridors within a 0.5 meter horizontal range (see Fig. X). This range exists because we didn't want them to get too close to the walls in case there were objects on the ground it couldn't detect, but we also wanted the robot's to be able to navigate around obstacles should there be people in their way. In addition, after defaulting the robot to particular centerlines following American traffic patterns (travel on the right side of the corridor), we saw the robot's were wearing lines into the carpets, so we added a random variable that ensured the robot would vary its offset from center.
The existence of this range within the robot's horizontal offset also means there is space to incorporate expressive motion via path shape. For example, we have implemented features that change the robot's straight-line path to one with oscillation, which, in our human study appears to communicate the robot's curiosity or possible loss of localization, depending on how it orients along the path. Similarly, the robot's timing constraints, for example, how long it has before it needs to deliver a message could change what range of speeds it might use to reach its destination.
The next step is to generate motions that make use of the motion feature parameterizations. This step should be integrated in the robot's motion planner. In our case, we used the CoBot's pre-existing navigation system to generate path waypoints, traveling between waypoints following our expressive motion parameters. The robot's current motion parameters were saved to a configuration file, and when the robot needed to decide what oscillation level to use, the system would look to the oscillation amplitude parameter in the file. So if the amplitude was set to 0.0 meters, which happened automatically if the robot has a direct Space Effort setting, the robot would travel along a straight line. However, if the oscillation were set to 0.5 meters (the maximum range, as you remember), the robot would then automatically travel down the hallway in a highly indirect manner.
We also found it necessary to specify priorities and feature ranges such that the feature application order occurred consistently, because some features impact others. For example, a small range of motion could truncate the desired speed if we prioritize acceleration, or make for extremely jerky motion if we prioritize speed. Part of our calibration process was to hardcode limits on particular motion features given the current Laban Effort Setting.
The final step is to perform studies with people to learn what parameterizations of the available features best communicate particular robot states. Incorporating people into the loop can happen in a variety of ways. We might start with a set of states, and bring in an expert to iteratively author parameters for rushed, friendly, lost, or whatever else. Alternatively, we could show people all possible permutations of the features we have, and ask them what they state they think the robot is communicating, possibly discovering states the researcher hadn't previously considered that we want to use or avoid.
For example, we have found that fast motion communicates 'busy,' regardless of path shape, and will impact people's likelihood to interrupt a robot (naturalistic study). Motion can also communicate affect, for example, that sad motion is slower, often with low frequency oscillation (motion tracking experiment). Motion patterns can even influence people's ratings of the robot's confidence, usually expressed via moderate to fast speed, with direct path (also from motion tracking experiment).
That summarizes the process for setting up, using, and training the Expressive Motion into your robot, but once you have a system capable of communicating with motions, what do you do?
After completing our descriptions of our Laban Effort Framework, we discuss useful tips for integrating Expressive Motion into your robot's behavior system, and areas for future extension. For example, how does a robot decide when to update its internal state? How does the robot perform a multi-step task with consistent state communications? Are there times it should escalate to other modalities or expression, even if that means interrupting it task? We outline possible answers to these questions...
There are many remaining questions for researchers to resolve about the challenges and utility of incorporating robot motion into a robot's behavior system. The best way to extend our knowledge of this space is by getting as many people as possible to start using Expressive Motion, so we hope that this guide will help you get an Expressive Motion system up and running on your robot. Words of advice: incorporate human evaluations as much as possible, invite performers into the lab, and iteration is your friend. Come be part of the excitement!
(Thanks Matt from GCC)
---
BACKGROUND
Robots are finding increasing numbers of applications in human environments, where they benefit from communicating with people. The goal of this paper is to explore expressive motion, a subtype of robot body language that people automatically read and interpret because of its cognates to how we communicate with each other.
This is increasingly relevant at a time where industry is investing in collaborative robots on the factory line, where human operators help coordinate the robot's tasks. The operators often work out of visual range of the robot, bringing it supplies or picking up parts that it has completed, as necessary, e.g., at 20 minute intervals.
For example, in a recent ethnographic study with the Baxter robot, researchers found:
- Humans working with robots automatically look for non-verbal cues about their task status. Operators, who were busy with their own tasks, diagnosed whether the robot was broken or needed help first via sound (the motors stopped whirring, objects were falling on the ground, the pattern of sound changes), then looking to the robot's 'face,' a screen with eyes. The robot's eyes were programmed to look at a part before reaching for it and show 'surprise' to acknowledge a person entering its environment (among others), and the operators found it helpful to look to the eyes from the distance, inferring whether they needed to help the robot.
- People working in close range with robots also appreciate and express the desire for more natural social communication with robots. The Baxter operators talked to friends and family about the robot as a 'colleague' who would have 'good days' and 'bad days.' They expressed a variety of anthropomorphic intentions to the robot, such as waiting until the operator stepped away to do something wrong, 'I swear it was just waiting until I went to the bathroom' and 'I feel like that thing needs a babysitter.' They also had strong emotional responses to its operation, 'sometimes he just makes me so mad.'
SIGNIFICANCE
The advantages of Expressive Motion include more fluent coordination between people and machines and simplicity of hardware. The essential idea of our work is that the common robot form-factors of today, which are generally quite simple, can leverage expressive motion while getting things done.
The benefits of Expressive Motion are twofold:
- Expressive Motion can improve functionality by improving communication
- Expressive Motion can add social value to human-robot interactions
Further, we see that people working with robots appreciate the non-verbal features included in the robot's face, but desire increased levels of social interaction. Expressive Motion is a useful channel to do that with, because it requires no new hardware and is visible from far away. Unlike Baxter's robot on-screen face, it requires no additional expense in hardware, but extends well to multi-modal communication. Motion is also a channel that applies to all robots.
APPROACH
Our approach is to layer these expressive motion on the task motions the robot is already performing. We do this by operationalizing a system from Dance and Theater training called the Laban Effort System, which identifies generalizable motion characteristics that could apply to any robot platform.
Layering: Most robots have motion features that they could vary while still accomplishing their task goals. An autonomous cars has a range of acceptable speeds that it can choose from on the highway, a variety of acceleration patterns that it could use to get up to those speeds and a range of acceptable distances it could maintain from the car in front of it.
Generalizable: The Laban Effort System provides qualitative rules of thumb for what aspects of those motion features influence people's perception of its current expressive state. These features would be equally applicable (after calibration) to autonomous cars, as to robotic vacuum cleaners or hospital delivery robots. Past work has shown that legible motion improves performance on the factory line. Our work would increase the variety of states a robot was capable of communicating through motion.
This approach contrasts with previous work, which, while showing expressive motion to be helpful, has often used animators to craft individual motion sequences (not scalable) or inserted gestures into the robot's motion sequence that could interrupt its functional motions.
AUDIENCE
We will share our approach and experimental results, and hope they will prove useful and applicable to other researchers. We acknowledge that there are other ways to use parameterized motion features, and welcome you to pick and choose what parts work for you, refining the particulars to your application setting or research.
By way of illustration, I can think of two audiences for whom this work could be useful. On the one end of the spectrum are the designers. For example, recent work on roboticized furniture establishes that people can read abstracted motion patterns, for example, a robotic ottoman inviting you to put up your feet (or get them down), or set of desk drawers opening in an energetic or lethargic way seeming to have varied levels of desire to help you. For a designer, a rounded knowledge of the space of Laban Effort features could open up hand-crafted explorations to motion features you had not previously considered. These features build on the expertise of dance and acting experts that has been leveraged and case-tested for over seventy years.
On the other end of the spectrum are roboticists working in manipulation that find the idea of expression interesting, but also need to optimize over many other task considerations (path length, collision likelihood, grasp success probability). Algorithms people want the expressive content of a particular robot path instance, e.g., 'urgency,' to reduce to a single number that they can then use to evaluate the hundreds of proposed path samples their motion planner comes up with, before selecting the 'best' solution. Using this guide, you could follow a similar process of training 'urgency' features, but this time in a continuous fashion, such that you can establish a 0-1 scale rating how urgent particular motion features or Laban Effort Settings appear.
METHOD
So how do we incorporate Expressive Motion into a robot Task?
The first step is to identify the feature space available for motion expression. The constraints here include the robot's hardware limits (D.O.F.s) - you can't include an orientation feature if the robot doesn't orient; and software limits - you can't include acceleration features if the motor controller doesn't support acceleration. The motion feature constraints will also come from the robot's task; you can't use average speed features if the robot is already required to hit a beat at a particular rate, but you may be able to vary acceleration profile.
Within most robot tasks, there is an allowable range of motion features. For example, the CoBot robots (one of the central platforms for this project) navigate down office corridors within a 0.5 meter horizontal range (see Fig. X). This range exists because we didn't want them to get too close to the walls in case there were objects on the ground it couldn't detect, but we also wanted the robot's to be able to navigate around obstacles should there be people in their way. In addition, after defaulting the robot to particular centerlines following American traffic patterns (travel on the right side of the corridor), we saw the robot's were wearing lines into the carpets, so we added a random variable that ensured the robot would vary its offset from center.
The existence of this range within the robot's horizontal offset also means there is space to incorporate expressive motion via path shape. For example, we have implemented features that change the robot's straight-line path to one with oscillation, which, in our human study appears to communicate the robot's curiosity or possible loss of localization, depending on how it orients along the path. Similarly, the robot's timing constraints, for example, how long it has before it needs to deliver a message could change what range of speeds it might use to reach its destination.
The next step is to generate motions that make use of the motion feature parameterizations. This step should be integrated in the robot's motion planner. In our case, we used the CoBot's pre-existing navigation system to generate path waypoints, traveling between waypoints following our expressive motion parameters. The robot's current motion parameters were saved to a configuration file, and when the robot needed to decide what oscillation level to use, the system would look to the oscillation amplitude parameter in the file. So if the amplitude was set to 0.0 meters, which happened automatically if the robot has a direct Space Effort setting, the robot would travel along a straight line. However, if the oscillation were set to 0.5 meters (the maximum range, as you remember), the robot would then automatically travel down the hallway in a highly indirect manner.
We also found it necessary to specify priorities and feature ranges such that the feature application order occurred consistently, because some features impact others. For example, a small range of motion could truncate the desired speed if we prioritize acceleration, or make for extremely jerky motion if we prioritize speed. Part of our calibration process was to hardcode limits on particular motion features given the current Laban Effort Setting.
For example, we have found that fast motion communicates 'busy,' regardless of path shape, and will impact people's likelihood to interrupt a robot (naturalistic study). Motion can also communicate affect, for example, that sad motion is slower, often with low frequency oscillation (motion tracking experiment). Motion patterns can even influence people's ratings of the robot's confidence, usually expressed via moderate to fast speed, with direct path (also from motion tracking experiment).
That summarizes the process for setting up, using, and training the Expressive Motion into your robot, but once you have a system capable of communicating with motions, what do you do?
After completing our descriptions of our Laban Effort Framework, we discuss useful tips for integrating Expressive Motion into your robot's behavior system, and areas for future extension. For example, how does a robot decide when to update its internal state? How does the robot perform a multi-step task with consistent state communications? Are there times it should escalate to other modalities or expression, even if that means interrupting it task? We outline possible answers to these questions...
There are many remaining questions for researchers to resolve about the challenges and utility of incorporating robot motion into a robot's behavior system. The best way to extend our knowledge of this space is by getting as many people as possible to start using Expressive Motion, so we hope that this guide will help you get an Expressive Motion system up and running on your robot. Words of advice: incorporate human evaluations as much as possible, invite performers into the lab, and iteration is your friend. Come be part of the excitement!
Subscribe to:
Posts (Atom)