The agent now can visually detect objects and add them to its internal model of the world. All the environmental hints pushed to the agent at startup have been removed, so it has to visually discover everything on its own.
In the video below, the agent demonstrates using its new eyes to visually navigate around obstacles and to find a way point which is hidden out of sight. It starts knowing nothing as usual, and quickly learns it can’t go through walls. It then searches for the hidden waypoint and learns that it’s at the end of a U-shaped hallway outside of the room. It then goes back to the starting point and repeats, this time much more quickly since it knows about the walls now.
The visual subsystem uses image streams from the color camera and the depth camera on the agent robot to detect objects, though it doesn’t need both for basic detection. The depth data is roughly similar to a LiDAR system.
When an object is detected, it calculates a bounding box (above) and passes that to the environmental model, which then tracks the object as a surface point-cloud. The images below show the agent environmental model compared to the actual environment.
Object Detection vs. Recognition
Before being able to see, the agent knew that a charger, for example, was distinct from and different from a wall. It could navigate to the charger and learn to charge. Now that the environmental hints are gone, it doesn’t know that a charger is a charger, so it has a harder time learning to charge because it can’t visually differentiate between a wall and a charger – it detects the charger but can’t recognize it (yet).
Detecting objects is a precursor to recognizing objects. Because the design requirement is that the agent has to learn everything on its own, it can’t use a pre-trained convolutional neural network (CNN) to recognize objects (because it would be impossible to pre-train a CNN on every possible object the agent could ever see). That means it will have to train itself, which means it needs to be able to detect an object before it can learn to recognize it, which is planned for version 0.5. So for now, it knows an object is there and it knows how to navigate around it, but it doesn’t know what the object is exactly.
And so it goes: as new functionality is added to replace old duct tape, the AI is required to be smarter in order to deal with its new self. Spiral development.
If you’ve watched any of the videos of the agent going around doing things, you’ve seen it shoot lasers randomly on occasion. You might be wondering if we really want robots all around us with frickin’ lasers on their heads. Fair enough. Here’s a couple of reasons:
From a technical perspective, It adds complexity to the experience the agent has in the environment. Firing lasers adds heat rapidly to the bot when fired, then it cools down slowly. They also drain the battery rapidly. The agent now has to figure out if any of those changing states were causual to anything it’s intending to accomplish now. It forces complexity into the scenario, which is good for learning.
From a safety perspective, it provides a concrete way for the agent to do something wrong. What’s better: build an AI, put it in a robot in the real world, and see if it shoots somebody? Or, put the AI in a simulated bot in a simulated world and see if it shoots somebody. When (not IF) it does, the simulated world is the perfect test bed for making the safety systems more robust before the AI has a chance to do something bad in the real world.
For example, what if the agent learns that to get past a certain type of obstacle, it can either go around it, or just shoot it. Then, what if it decides to try that on a human and see what happens? There are many issues surrounding AI safety that need to be dealt with, many much more subtle that this scenario. Giving it lasers is one way to approach the problem. Or in general, setting it up to be able to fail in order to see how it creatively fails so that more robust safety systems can be developed.
There’s all sorts of ways to imagine an AI running around the pool with knives. This type of approach doesn’t cover all bases, not even close. But it adds to the pile of test methods that will be needed as it gets smarter.
The agent has been restricted to solving one-dimensional problems so far, but now the planning engine has been updated to allow n-dimensional planning. One simple example of this is being able to intentionally navigate around obstacles, whereas before it could not.
There are significant changes on the whiteboard for the planning engine in the near future which will add more versatility and functionality to the agent’s reasoning ability.
Also, recently updated the environment to be a boot camp-style training course to facilitate the initial curriculum training it will need to do more complex tasks later on.
The AI can navigate around a room between way points using fwd/cw/ccw controls. OpenAI games are in place but sync issues are not debugged yet.
Curriculum training is accomplished with progressive goals designed to help the agent to learn specific actions, and to allow it to discover the importance of prerequisite state requirements, from which it builds plans to meet objectives with.
After training this agent demonstrated, upon receiving an internal motivation to charge its battery (‘low-battery’ alarm), the ability to find a charger, connect to it, charge, disconnect, and continue on.
Moved the project back into the Unity 3D environment from the 2D python environment it was using. The agent AI is written in python, the agent bot is in C#.
This video shows the agent learning how to move in the environment. It can only move forward, and turn clockwise and counter clockwise. It can’t move backwards or strafe to the sides, so it has to learn how to point in the correct direction before moving forward to get there. The agent learns quickly which actions are most likely to help it achieve its goals.
The AI can navigate around a cluttered room using fwd/cw/ccw movements to a series of waypoints in level0-6.csv, but it cannot intentionally navigate around large obstacles. OpenAI games CartPole_v0, MountainCar_v0, and LunarLander_v2 are implemented as world objects and the agent can navigate to and play these games, with varied success. The agent has been observed to make perfect landings in LunarLander_v2, and has scored above the threshold on the other games within a few tries (less than 4 generally), however consistency is lacking after initial successes.
The AI was given 4 waypoint goals (state = ‘GPS’) in Level 0-0, and it was able to learn how to navigate rapidly (within about 10 steps), and then navigated to each of the 4 goal locations using a simple difference planning engine, which was kind of a hack but was added to the AI for the purpose of demonstrating that the CE/CM works.
The AI was designed to play OpenAI Cartpole-v0. It was not consistent however – usually performing moderately well, on occasion performing very well. Sometimes it performed terribly. Typically though it was able to reach an average of 195 steps in a 500-run test.
Version v0.1 was a move from C# in the Unity3D environment to python, since much of the AI community uses python, it seemed a good shift. The agent was based on a very simplified rlpAI architecture with a scikit-learn MLP Classifier as the centerpiece.
The agent trained the classifier (state input, action output) with some of the results of prior episodes. In the best test, the agent reached 200 steps in less than the first 10 episodes, then hit 200 steps on every episode after that for 500 episodes (bottom right chart).
Vertical axis: Number of steps completed in the Cartpole-V0 game. Horizontal axis: Episode number.
The environment is a simplified ‘reality simulator’ running in the Unity 3D game engine.
Simulates physics and object collisions
Provides cameras for robot vision
Environments can easily be swapped to focus on specific aspects of the agent
Behaviors and functionality can be programmed into objects
Unlimited world size – the world can be as big as the agent can explore
Level of detail can be tailored to the agent’s needs
The Unity machine learning agents add-on provides a Python API
Partially (vs. Fully) Observable: While this is also a function of the robot sensor limits, the world is a very large place, and the agent does not have access to all the information in the environment as a matter of course (as apposed to a chess-playing agent, which knows the entire chess board state at all times). In fact, an environmental observation is entirely up to the agent, as the environment doesn’t care about any agents within it.
Stochastic (vs. Deterministic): Many of the early test environments have been built as static (as in not-moving) single-agent environments, but they are not entirely deterministic. The agent can’t predict the exact outcome of all actions all the time. As a simple example, the first time the agent runs into a wall, the outcome of moving forward is completely unexpected. The intent is to make the environment more dynamic (things moving around) and more stochastic as it evolves.
Sequential (vs. Episodic): The general environment is sequential. Once it starts, it keeps going. There can be episodic elements, however, such as games that the agent can play through the data port in the environment are mostly episodic in nature (such as Cart-pole, Tick-Tack-Toe, etc).
Static (vs. Dynamic): If the environment can change while an agent is deliberating, then the environment is said to be dynamic for the agent; otherwise, it is static. The environment is technically static since the agent is allowed to process one full observation/action cycle per time step of the Unity physics engine. The agent is tightly coupled for the time being in this cycle, though this will likely be decoupled in the future. This tight coupling causes the environment frame rate to vary based on how much the agent has to think through each frame (annoying), but allows development to move forward.
Continuous (vs. Discrete): States in the environment sweep through a range of continuous values and do so smoothly over time. For example, the agent or any object can be at location (0,0,0), or (1, 1, 1), or any location between those two points, up to the floating point limit of the machine. States observed through the data port are allowed to be discrete with a limited number of values, such as two-state indicators.
Single Agent (vs. Multi-agent): The environment is capable of having any number of agents, but most scenarios so far have only included a single agent. Having multiple agents in the environment will certainly happen in the future, including one or more humans via virtual reality.
3-Dimensional (vs. 2-Dimensional): The environment is three dimensional. An example of a two dimensional environment would be a board game such as chess or checkers.
Unity 3D game engine with the Machine Learning plugin (CPU and GPU)
C# for the robot, sensors, and game object controllers (CPU)