Supervised Learning

The most successful type of deep learning in industry is supervised learning, but using this type of learning comes at a cost. The crux of supervised learning is the need for labelled data which is usually laborious and expensive to collect. Services like Scale and Amazon’s mechanical turk exist to make collecting annotations a bit easier by offering outsourced and crowdsourced labor. However, determining ways to have the data labelled is only the first step.

There are many design choices to be made when determining the type of label for any task. Some options include motion trajectories, key poses, key points, and object poses to name a few.

Joint vs Cartesian Space

If you decide to use motion trajectories, should the trajectories be labelled in joint space (the position of the robot’s joints) or cartesian space (the position of the robot’s gripper or tool)?

Joint space enables end-to-end learning which can be utilized to minimize energy expenditure or avoid collisions to optimize the use of redundant degrees of freedom. However, joint space learning is more data hungry because the neural networks are forced to learn unnecessary things like inverse kinematics and low level motor controllers — both of which already have conventional solutions that run fast and work well without deep learning. Joint space learning is also robot specific since each robot has a different kinematic configuration of joints. Thus, joint space learning is not easily transferrable across different platforms in comparison to cartesian-space policies.

Regression vs Classification

The next step is deciding how to frame the learning problem. When our neural network makes predictions on how to act, it can regress to poses and velocities, or it can classify sampled actions as good or bad. Regression is continuous in action space allowing for more precise motion, but it suffers from learning the average of multiple valid actions, which may actually be an invalid action. Meanwhile, classification can handle multiple correct action modalities but is discretized and requires sampling and evaluating many possible actions which increases computation time.

End-to-end vs Pipelined Learning

As part of framing the learning problem we can choose to use end-to-end models where a convolutional neural network (CNN) ingests pixels from an image and — like a true black box — returns low-level joint commands, thus managing the entire robotics pipeline. Alternatively, we can use a pipelined approach where the robot has distinct modules for each processing step: sensor pre-processing, sensor fusion, perception, policy, motion planning, kinematics solvers and motor control. In the pipelined approach a CNN can be isolated to perform the perception part while other modules perform the remaining computations.

While neither is right or wrong, the real-world successes in robotics all use the pipelined approach today.

This is because the pipelined approach simplifies the learning problem which makes the total system more robust. It minimizes the chance of encountering weird bugs arising from a lack of transparency into how the black-box neural network makes its decisions.

The argument for end-to-end learning is that it can be more generalizable in its ability to use the same software and algorithms across many different scenarios and tasks. An end-to-end model might work well for low-cost, low performance robots where sensors are noisy, actuators aren’t precise and computational power is limited.

With the pipelined approach we can train a robot to perform robustly for a single challenging task using relatively little data and a decent amount of custom engineering. Alternatively with the end-to-end approach we can create a more generalizable model that can learn many tasks from the same software but requires significantly more data.

Below are some research directions which could eventually lead to neural networks performing increasingly more of the robotics stack.

Sim-to-Real

Given the chicken and egg problem robots face, it is unclear if collecting the ImageNet analog for robots today is tractable. However, by leveraging modern GPU-accelerated and parallelized simulators, we can generate ‘years’ of synthetic robot experience in a matter of hours and at very low cost. In addition to being fast and cheap, simulators can offer the advantage of automatic data annotation eliminating the need for manual human labelling.

The big challenge with synthetic data is that simulators (Unity, Gazebo, Mujoco, PyBullet, V-REP) and their physics engines (PhysX, Bullet, etc.) do not accurately represent the visual and physical complexities of the real world. Simulators struggle to precisely model things like friction, stiction, gear train dynamics, contact models, and the behavior of deformable materials under loads.

Similarly, synthetic visual data captured by rendering virtual scenes belong to a different data distribution (i.e. looks different) than images captured from real cameras. This distribution mismatch complicates simulation-to-real (sim2real) policy transfer where models trained in simulation fail to work equally well on robots in the real world.

The robot model shown below is trained to perform acrobatic maneuvers in simulation. The learned behavior hasn’t yet been shown to transfer to a real robot.

While the recent Boston Dynamics videos might suggest otherwise, their robots accomplish these maneuvers using well-tuned controllers built on top of physics models in calibrated environments — not machine learning. Boston Dynamics has proven that mastering traditional control, state estimation, inverse dynamics and trajectory optimization (MPC, LQR, etc.) in a pipelined approach still trumps machine learning in robotic control … for now!

To summarize, synthetic data collected from virtual sensors in a simulation doesn’t look exactly like data collected from real sensors. This discrepancy leads to a fundamental challenge known as the ‘transfer problem’ or ‘reality gap’ where policies learned on simulated data are overfitting to the parameters of the simulator rather than generalizing to the real world.

Domain Randomization

One technique called domain randomization can help bridge the ‘reality gap’. By training a policy on millions of simulated episodes and adding randomized jitter or noise to the parameters of the simulated environment, we can prevent overfitting to any one set of visual and dynamics parameters. This forces the network to focus on learning the details important to completing the task rather than learning to cheat the simplified rules of the simulator.

The goal during sim2real transfer is to run a policy trained in simulation in the real-world with the expectation that, to the trained network, the real-world will look like just another instantiation of one of the many randomly simulated environments on which it has been trained.

This training method allows the network to perform well on both simulated and real observations while only being trained on the former.

Building on vanilla domain randomization, a paper from OpenAI introduced Automatic Domain Randomization (ADR) which has 2 keys benefits for learning. Instead of manually defining the the bounds of the randomization for each jittered parameter, ADR starts with a narrow distribution of parameter values and automatically widens that distribution only when the learned model can perform the task well on its current distribution of randomized simulated data. This 1) forces the model to gradually learn complex tasks across a wide distribution (easier than non-gradual learning) and 2) doesn’t require engineers to manually tune the bounds of the randomizations which is unintuitive and unscalable.

The authors of GraspGAN take a different approach at transferring the reality gap. Instead of training on psychedelic-looking, randomly simulated data, they train a GAN. The GAN’s generator, a neural network, ingests simple images from a simulator and learns to generate images that the discriminator, another neural network, cannot distinguish from real camera images. Using this method, they can create a large synthetic dataset that ‘looks’ more real. The visuomotor policy can then be trained on this real-looking (but still fake) data.

More recently RCAN, or Randomized-to-Canonical-Adaptation-Network, achieves the same 86% grasping success on unseen objects as the original QT-opt model but does so using less than 1% of the original 580,000 training examples collected on a real robot. The RCAN method crosses the reality-gap by using a pixel2pixel cGAN which learns to transform domain-randomized synthetic images into their equivalent non-randomized, canonical versions. This in-turn allows for real images to also be translated into simplified canonical images. The grasping policy, QT-opt, is then fed these simplified canonical style images, and does not have the challenge of dealing with diverse visual inputs.

While sim2real methods have made significant progress in the past few years there is a very important distinction to make about the ‘reality gap’. In academia ‘real’ is often not defined strictly. Most of the time academics define ‘real’ as anything that works on a real robot as opposed to a simulated one. This means that ‘real’ usually ends up being defined as a highly simplified lab environment, with a dumbed down version of a task that only needs to work 40% of the time. In industry ‘real’ is defined as the full task, operating in a complex and dynamic environment that needs to work 99.9% of the time. Thus, the true reality gap isn’t sim2real but rather lab2industry.

Hybrid Sim2Real Learning

An approach that can help bridge the gap from simulation and simplified lab environments to industry is to combine learning in simulation with learning in the real world. Simulated data can be used for tasks in which sim-to-real works well and real data can be used where simulated data falls short.

One of the first sim-to-real demonstrations for learning complex legged behavior does just this. The authors train an end-to-end controller for legged locomotion. Their key insight is to train the actuator’s torque controller, which contains extremely difficult dynamics to accurately simulate, on real robot data, and use the simulator to learn the position controller, which can be easily simulated with a kinematic model.

For some tasks though, training on synthetic data at all just doesn’t work well enough and so we must obtain and train on real data.

Real-world Reinforcement and Self-Supervised Learning

A key distinction between imitation learning and reinforcement learning is the strength of the ‘reward’ signal. Imitation learning uses expert demonstrations which primarily encode how a task should be done, as opposed ways a task should not be done. Reinforcement learning uses both, good and bad examples, but because there are usually a lot more wrong ways to do something than right ways, the trial-and-error data collection process is very inefficient.

Determining the success (i.e. reward) of each of thousands of possible actions can be challenging to automate. Rewards are typically hand-engineered or shaped for a specific task and it isn’t trivial to build a single highly generalizable reward function that works across many different tasks.

One type of RL, model-based RL, first learns a model which approximates the underlying system dynamics and then uses this model for planning or to subsequently train a policy. Model-based learning enables modifying the goal of the robot within an environment since the dynamics of that environment are understood.

Another type, Model-free RL, directly learns a policy without an explicit representation of the system dynamics at play. While more generalizable, model-free RL has the classic trade-off of also being more data hungry.

While promising, robotic reinforcement learning hasn’t really seen much success in industrial applications. There are several reasons why.

First, RL in the real-world is time consuming because, unlike in a simulator, the number of experiments can’t be parallelized with respect to time and hardware. Additionally, real robot RL requires a significant engineering effort to ensure things don’t break during data collection. This constraint naturally leads to less data diversity since robots can only explore within an engineered environment rather than any and every environment. Less data diversity usually means the robot can only perform well in environments similar to the one it was trained on which kind of defeats the purpose.

For a more detailed summary on the challenges of RL see Alex Irpan’s blog post.

Teleoperation and Imitation Learning

While self-supervised learning can be used to collect a lot of real robot experience via trial and error, these methods are data inefficient — they require exploring vast state and action spaces. Additionally, defining good and bad actions (i.e. reward shaping) can be unintuitive and result in unintended behaviors...see the boat controller below.

The search space for RL can be reduced significantly by sampling from a much narrower distribution centered around human demonstrations but acquiring ample human demonstrations requires intuitive methods of controlling robots. A good way to collect human demonstrations for robots is through teleoperation.

There are various interfaces for teleoperating robots, ranging from complex haptic controllers with virtual reality headsets to hardware minimalistic systems, like mobile devices and marker-less pose estimation. More dexterity typically means more hardware and cost, but a crowd-sourceable interface should utilize ubiquitous hardware. In an ideal scenario robot data collection can be a byproduct of useful, crowd-sourced telerobotic labor.

While crowdsourced teleoperation is conceptually appealing, one practical challenge with remote teloperation is handling latency. Controlling a robot 1 mile away with 20 ms latency would be a completely different experience compared to controlling the Mars rover located 34 million miles away with 7 minutes latency.

A way to mitigate latency all together is by using asynchronous control — NASA does this. The trade-off is a sacrifice in fine temporal motor control and the ability to react quickly which is why the teleoperators at the DRC couldn’t save their robots from falling.

3rd Person Imitation Learning

Beyond teleoperation all together, it would be convenient to teach robots in the same way humans learn — by watching others. The challenge in doing this with robots is the radical domain shift in learning a skill that is demonstrated in different morphology than that of the robot. A human arm and hand look and move differently than a robot arm. Asking the robot to perform the same task with a different ‘body’ only adds to the learning complexity. The advantage of 3rd person imitation learning is that we can train robotic policies from thousands of already existing YouTube videos of people doing stuff.

Learning from Play

Learning from play combines the advantages of simulation and teleoperation. Its idea is to have humans play by teleoperating virtual robots to interact within virtual environments. The distinction of play data vs. task demonstration data is that play is interested more-so in understanding an environment than in achieving any single resulting outcome state. This trait allows for efficient exploration of various ways to interact with and exploit an environment.

The motivation for learning from play is to enable robots to navigate and interact with environments by learning how to to accurately decode reusable latent plans rather than learning the prohibitively large encoding for the full state-action space. Additionally, the properties of play as compared to expert demonstrations allow learned policies to be more robust to perturbations and recover from failures more effectively.

What’s Next?

The holy grail of machine learning and artificial intelligence is something people refer to as AGI or Artificial General Intelligence. It essentially refers to a level of intelligence in machines that matches or exceeds a human’s ability to learn new skills on the fly with just one or a few demonstrations of any new task.

There is a lot of hype surrounding this term and while it’s not yet clear if and how it will be achieved, there is a loose consensus that our algorithms need to be pushed towards generalizability through hierarchy. Transfer learning, Meta-learning, and Neural Task Graphs are steps in the right direction. These methods train models on a subset of all tasks with the goal of creating a model that easily transfers or generalizes to any new task by sharing previously learned low-level skills like grasping, pushing, and moving. Nearly all manipulation tasks require some sequential combination of these low-level skills. Thus, any task can be represented as a composition of low-level skills coordinated in time and space by a higher level controller. This hierarchical framework enables transfer and generalizability because models need not be retrained on large datasets for every new task. Rather, the same low-levels skills are shared and the higher level composition of these low-level skills, which make up most tasks, are the focus of learning for each new task.

Summary

While not exhaustive, I’ve outlined a few of the most prominent challenges roboticists face in pursuit of developing more intelligent robots that can help us outside of factories. More importantly I’ve outlined some of the potential avenues of research I’m bullish on. For those of you who want to take a deeper dive into robot learning here is a recent survey paper that cites 440 other publications!

My Utopian view of automation

The ultimate goal of all these robots is not to automate away all of our jobs. Instead, automation should free humans from the trillions of hours we spend each year on monotonous manual labor that could otherwise be refocused towards solving our seemingly endless list of more impactful problems like curing disease, solving global warming, scaling clean energy and food production and making humans an interplanetary species. To me, that sounds better than using people — and the many superpowers we possess — to pick and place things all day, every day.

About Me

I’m a robotics PhD student in Stanford’s Vision and Learning Lab and the Founder of Nimble, a startup building a robotic hive mind to automate complex tasks in warehouses.

Twitter: @simonkalouche

The evolution of intelligence in robots: Part 2 was originally published in DataDrivenInvestor on Medium, where people are continuing the conversation by highlighting and responding to this story.

When we think of the Skynet scenario, videos of increasingly nimble anthropomorphic machines from Boston Dynamics awe, or terrify, us. Just a couple years ago these humanoids developed an ability to get up when we knocked them down. Then, they began parkour-ing with finesse around our man-made obstacles. Now, they’re elegantly out-performing most humans in gymnastics. It all portrays a deceiving story of the rapid evolution of intelligence in robots. But in reality, these robots are still far from possessing the intelligence to fold our laundry, let alone become our overlords.

There’s a lot of hype playing into the robot takeover narrative. The purpose of this blog post is to present some exciting breakthroughs in robotics research while debunking fact from fiction.

Robots have been around and widely used in manufacturing since the 1960’s. While we’ve been calling them robots for all this time, a more fitting name would be ‘reprogrammable motion machines’. They are explicitly programmed to repeat trajectories exactly the same way, every time. They lack the intelligence to self-adapt if their environment or task changes even the slightest.

Now fast forward to today — almost nothing has changed. Nearly all deployed robot arms are still not intelligent and are confined to highly structured manufacturing environments. Yet, if we look beyond the walls of factories, the world is full of monotonous tasks across logistics, delivery, farming, construction, and transportation which are prime for automation. The reason many of these labor intensive jobs are not yet automated is because they inherently bear an enormous amount of variability — the achilles heel of robots.

One example of a repetitive yet enormously varying task is ‘picking and packing’ in eCommerce fulfillment centers. This job requires proper handling of millions of different products — all with varying sizes, shapes, weights, colors, textures, stiffnesses and fragilities. There isn’t a one-grasp-fits-all solution to handle any object. As humans, we take our innate ability to grasp, assemble, disassemble, reorient, fold, pack and generally manipulate any object for granted. For robots, this is very hard.

In addition to lacking general intelligence, robots are still very expensive. The mainstream arms from UR, Kuka, Franka, Yaskawa, Fanuc, and ABB start at $20k and can easily cost over $100k.

The inability to handle variability along with a high price tag makes it difficult to justify the economics of most robotic applications — this is the reason many robotic startups fail. If you replace a burger flipper in a fast-food restaurant with a robot, you are not replacing one employee. You’re replacing a lot less. In one minute a person can be flipping burgers. When they’re not flipping burgers they can be making fries, wiping tables, cleaning bathrooms or taking orders. Replacing a small fraction of a minimum wage employee is not financially compelling, especially given the cost and practical complexity of implementing such a piece of technology. A lot of robot applications suffer from this dilemma.

Building a viable robotics use-case

If your goal is to build a valuable robot application and deploy it successfully in the real world today, then my recommendation is to consider the following:

1. The price you charge your customer should be a fraction of the total cost of labor you are replacing over some reasonable period of time (usually no more than 2 years). Alternatively, the demand for the labor your robot can perform should be extremely high, to the point where the pool of available human labor is not willing or able to provide the total labor needed.

2. Robots aren’t people. Retro-fitting an environment designed for humans with robots will ALWAYS be less optimal, in the long-run, than designing the environment around the robot’s capabilities. Robots love structure, so give them as much structure as possible so long as it does not impose unreasonable cost or additional labor on the customer. In the same vein, we should not design robots to exactly mimic things we find in nature. Just because humans do things a certain way doesn’t mean there isn’t a simpler, more optimal solution enabled by modern engineering. See Rubik’s cube example…

3. Build a solution that works really well for one domain where you can automate a task well today within that domain and have line of sight to automate more tasks over time in that domain with the same robot. In most applications the customer expects a solution, not a piece of the solution they then need to stitch together with other technologies to make an actual solution. In addition, this solution is usually expected to work 99.9% of the time. As good as 95% success (in a simplified lab scenario) might sound in academia, that won’t cut it in industry. Following the standard learning curve and Pareto principle, the last 5% is the hardest to obtain and almost always comes down to engineering edge cases versus fundamental research. Focus on one whole product and deliver it super reliably.

4. Choose a task that robots are capable of reliably performing within a few years. If you can’t fully automate the task with 99.9% reliability today, then narrow the scope of the task, add more structure, or use teleoperators to handle edges cases. As long as the teleoperator-to-robot ratio is economical, teleoperators can give robots the dexterity they need today while helping train them to become increasingly intelligent and fully autonomous over time. Nimble, Phantom Auto, Kiwi, and others do this.

Boston Dynamics, the most advanced robotics company in the world, has struggled to successfully commercialize their robots because of their high cost and unclear value. While their videos amaze us all, at the end of the day two metrics, cost and value, determine the adoption of any technology. Robotics — no matter how cool — are no different.

This blog post discusses the progress being made to improve robot’s cost:value ratio (what I’ll call the Jetsons ratio) by orders of magnitude so that we can continue to deploy more robots in the real world in increasingly more challenging and useful tasks.

The Robotic Chicken and Egg Problem

At the heart of the currently terrible Jetsons ratio is a classic chicken and egg problem. Robots are expensive because they aren’t yet mass produced. They aren’t yet mass produced because they don’t yet offer real value to the common consumer. They don’t yet offer value to the common consumer because they aren’t yet intelligent. They aren’t yet intelligent because there isn’t a large-scale dataset on which to train them. There isn’t a large-scale dataset because robots aren’t mass produced. We’re back to the beginning.

However, there is an out to this vicious cycle and it’s through riding the success waves of the commercial drone industry and deep learning research.

How drones catalyzed low-cost robots

Recent market factors like the explosion of the consumer drone and scooter industries have justified the mass production of robotics-grade motors and electronics. While not specifically designed for use in articulated robot limbs, these components have catalyzed the emergence of a new generation of low-cost robots.

Research from the legged robot community produced a new low-cost but high-performance actuator called the quasi-direct-drive actuator. Robots like GOAT, Minitaur, and MIT’s Mini Cheetah have been designed to balance the inherent trade-offs between force control (required for safe interaction with humans), high torque density (required for interacting with household objects with a reasonably sized robot), mechanical robustness, and low cost. Similarly, the $5,000 Blue arms utilize the same quasi-direct drive actuation scheme to enable a capable, force controlled manipulator at low cost.

The secret to these super low-cost robots was retro-fitting mass-produced ‘drone’ motors with custom drive electronics, low-cost magnetic encoders, single-stage transmissions and advanced field-oriented control. This combination forged the path for high-performance robotic actuators at a tenth the cost of traditional robotics drives from vendors like Maxon, AMC, Elmo, Harmonic Drive, etc. This innovation will be an inflection point in the coming robot revolution.

Deep Robot Learning

Deep learning, while not the answer to all our problems, offers the promise of liberating robots from manufacturing into use-cases with significantly more variability. Instead of programming robots explicitly for any and every scenario, deep learning, while data hungry, leverages experience to learn control strategies that can adapt to new scenarios on the fly without explicit instruction.

Unlike most deep learning applications, which perform visual understanding and reasoning, robots need to be able to act in response to their perceived environment. Doing so requires a precise spatiotemporal understanding of the world. This requires significantly more data than using a neural network to determine if a picture contains a dog, cat, or airplane.

The dearth of a diverse, large-scale robot dataset is at the heart of our chicken and egg problem and there isn’t much of a consensus on how to collect a widely useful one. Unlike videos, audio, pictures, and text which are abundant online and in everyday life, robots aren’t. Collecting data on real robots is time-consuming, potentially dangerous, and expensive.

With a deployed fleet of low-cost robots, learning is certainly scalable though. Each robot can learn from every other robot’s collective experience so that every new robot deployed in a distributed network need not be retrained — a true robot hive mind.

Before deploying a fleet of low-cost robots, we first need to answer 4 questions to ensure that we can properly learn from the collected robot experiences.

1. What dataset size and distribution is needed to generalize a learned task to different situations?

In the context of creating a personal, in-home robot we would want the same robot to work equally well in my home and yours. But the problem is every home is radically different. Different furniture, different lighting, different flooring and layouts, different door knobs and appliances … different everything. How do we determine the appropriate sample size and diversity of data to be collected so that robots don’t overfit to the set of homes on which they were trained and instead can generalize to open doors or clean up rooms equivalently well in any home?

2. Which suite of sensor data is most conducive to learning?

Do we need visual data from cameras; 3D point cloud data from depth imagers or LIDAR; trajectory and motion data from encoders; tactile, proprioceptive or haptic data from load cells, soft artificial skin sensors, the GelSight sensor; or some complex combination thereof?

Different tasks most likely require different sensing modalities. Grasping an item may only require cameras but reorienting the object once it’s been grasped may be done more efficiently with some form of haptic information.

The same question exists for self-driving cars. On one hand, Elon Musk claims that fully self-driving vehicles can be achieved without expensive LIDARs. On the other hand, many top AI researchers and other self-driving car companies like Waymo disagree. There isn’t a strong consensus on the minimal set of sensors needed.

3. What’s the best reward signal for our data?

Possibly the most difficult question is determining how to inform robots if their actions during each experience are successful so that they can learn which actions lead to success and which lead to failure. Robots can be engineered in ways to do this automatically via self-supervision or reinforcement learning. Alternatively, humans can manually provide demonstrations or annotations indicating successful versus failed actions. The hard part is determining a generalizable framework for defining rewards such that each task doesn’t require its own list of finely tuned conditions or demonstrations in order to classify behaviors as good or bad.

4. How should we frame the learning problem?

Do we learn end-to-end models, or is it smarter to utilize human intelligence to frame tasks in ways that simplify what the neural network must learn? For example, with grasping we can try to learn end-to-end 6-DoF grasp poses directly from raw pixel inputs. Alternatively, we can frame grasping as an image segmentation problem using fully convolutional networks to classify each pixel as a good or bad area to grasp an object at and, as a post-process, use surface normals computed from depth images to obtain the full 6-DoF grasp pose. The latter method is more data efficient since the problem is simplified and the action space is reduced from 6 dimensions to 2. The classic trade-off to this simplified approach is that the method is no longer generalizable to many different manipulation tasks — each subsequent task will require significant re-engineering and data collection.

Similarly, OpenAI trained a high degree of freedom Shadow Hand, to solve a Rubik’s cube. However, instead of training the neural network to ‘just solve the cube’ in and end-to-end fashion, they broke the problem down into many sub-problems using a pipelined approach. To actually solve the cube’s puzzle they use a conventional cube solving algorithm — Kociemba’s algorithm. Instead of using a camera to determine the state and orientation of the cube through visual perception — like humans — they instead retro-fitted the cube with a variety of internal sensors. Instead of learning to generally manipulate any face of the cube, they use human intuition about which face the hand was best at rotating (the top face), and constrain the solution moves to only rotate the top face. In this way they took a complex problem like solving a Rubik’s cube and significantly simplified the learning task by narrowing the scope to simply learning 1) how to rotate just the top face of the cube and 2) how to reorient any face to be the top face of the cube. They left the rest to conventional engineering and non-learned algorithms.

While manual engineering subgoals makes the learned skills less generalizable, it makes the task at hand easier to learn and the performance more reliable. We’ll talk more about the end-to-end vs pipelined approaches in Part 2.

There are many system architectures whose design choices have inherent trade-offs and implications on how much data you need and how well your eventual model can generalize to different robots, different tasks and different environments. Knowing what to have the neural network learn and what kind of data it should learn from can significantly reduce the amount of data needed.

Part 2 of this post discusses clever, state-of-art research directions for ways in which we can make progress in addressing each of the 4 questions outlined in this post!

About Me

I’m a robotics PhD student in Stanford’s Vision and Learning Lab and the Founder of Nimble, a startup building the robotic hive mind to automate complex tasks in warehouses.

Twitter: @simonkalouche

The evolution of intelligence in robots: Part 1 was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.