Control and interface with real hardware within AnimatLab can be done by adding a robot interface to an existing simulation. The concept behind adding robotic interfaces is that you are really just defining the IO properties for the real hardware that corresponds with parts in your simulation. So think of these components more like translators between your simulation components and the real hardware. For example, you may have a hinge motor in your simulation, but to connect that to a real servo you will need some additional information like its ID, the com port it talks on, its BAUD rate and so on. The robot interfaces allow you to define how the simulation components and real components will talk to one another by specifying just a few key parameters. Once you have setup those key parameters, then all the work of actually making the robot hardware move using neural networks is already built into the framework. If you have specified in your simulation that a firing frequency of x will cause the motor to move at rate y, then the real system will do that as well. As a motor moves its position will be read back from the physical motor and update the position variable in the simulation component. So if you have setup your simulation to trigger a neuron to fire when the motor is beyond a certain angle, then this will happen just as it would in the simulation. Essentially, with this framework you need to know virtually nothing about programming or embedded systems to connect your simulated object up to control real robotic hardware.  

The framework does this by allowing you to add one or more robot IO control systems. Each controller you will interact with will have an IO control component specific for it, and you can have as many of these IO systems in your simulation as needed. Each IO system has the option of adding robot part interfaces to connect with specific body or neural components within the simulation. For example, the Firmata system shown below has digital and analog input interfaces, in addition to standard and Dynamixel servo outputs. Different IO controllers will have different types of parts it can control or read from. There are currently a few different IO systems available. Please see the details for each of these for a more in-depth description of how to use them. We will continue to add more IO controllers in the future to allow the system to talk to more and more different types of hardware.

Each Robot IO controller runs its IO in a separate thread in the background. This allows it to try and do its IO as fast as possible, and then when the simulation takes its time step it pulls the latest settings, and gives the IO its latest commands. Below is a list of the currently available Robot IO controllers. Please see the individual pages for a more detailed description of how to use each one.

• Robot IO Controllers: Describes what the IO interfaces are and how to use them.
• Dynamixel USB: This uses the Dynamixel USB interface to allow you to control Dynamixel servo motors directly from the simulated motors.
• Firmata: This communicates with an Arduino microcontroller board to allow you to control motors and read sensors. It also works with the Arbotix board to allow you to control Dynamixel motors.
• XBeeCommander: This reads in serial data from the XBee Commander remote control to allow you to use stimulate neurons directly so you can control you simulations and real robots.

 

The first step is to get a basic simulation working like you want. Build the robots body, along with motorized joints and sensors the same way you intend to build the real system. Then put together your neural control system that will create its behavior. After you have that in place you can start adding the robot interfaces. Right click on the robot organism node in the treeview and select Add robot interface. For the moment there is only a standard one available. With this one you will need to generate a simulation project file and then transfer it to your robot and run it manually. Eventually, there will be a wifi option so you can transfer it to the robot and interact with it in real-time. Once you have added the robot interface a new node will be created under the organism. It has several important properties. 

 

• Enabled: Setting this to false will disable all robot control systems.
• Robot Time Step: You define a physics time step within your simulation. However, that only applies to the simulation itself, and is usually a fairly small value so the physics engine will have a small enough delta to be able to compute changes without becoming unstable. When you are running on real hardware the physics time step is not necessarily going to be the same as for your simulation. This allows you to control the time step used on the real hardware. You should typically set this based on what your slowest IO loop is going to be. For example, the Dynamixel USB controller running on a Windows OS takes around 2ms to query a give motor. If you have 3 servos in your system then it will take at least 6ms to get updates for all the motors, so you would probably set the physics time step of the robot interface to 6ms. However, for that particular example there are some things you can do so you can lower that time. The DynamixelUSB IO control allows you to poll motors in a round-robin fashion. So it would still take 6ms to get the update status on all motors, but you could do make your physics time step 2ms to get a faster motor update rate. Bottom line here is that this setting is something you are going to have to give some real thought to and experiment with to make sure you can get the IO you need within that time and do whatever neural processing is required.
• Synch Sim: There are often hard, physical limits on how fast you can update your data on a real system. In order to get the simulation of the hardware as close as possible you will need to update the IO on the simulation at a similar rate. If this flag is set to true then it will look at the settings on adapters to try and match the simulated IO to what would be seen in the real hardware. We will discuss this more with adapters below.

There are often hard, physical limits on how fast you can update your data on a real system. In order to get the simulation of the hardware as close as possible you will need to configure your simulation to update data in a similar manner. There are a number of new features that were added to AnimatLab to allow you to do this. Most of these were added to the adapter configuration. There are now several new adapter settings that relate to robot control. Below is a list of them and a description of how to use them.

• Delay Buffer Mode: This allows you to setup whether you want a delay buffer between the input and output of your adapter, and if so, then when you want the buffer used. There are three options. NoDelayBuffer will not use a delay buffer. DelayBufferInSimOnly will use a delay buffer while running in simulation mode, but will not use that buffer when running on real hardware. DealyBufferOnAlways will always use a delay buffer. A delay buffer on the adpater can be very useful to try and match your simulation to the real system. For example, there is a ~200 ms delay between sending a command to the DynamixelUSB controller and when it actually takes effect. You can model this using a delay buffer in sim only with a 200 ms interval. When you run on the real hardware it would have a similar delay, but only because that is a hardware limitation and not because of our buffer. This allows you to more closely match the simulation output to the real hardware system.
• Delay buffer Interval:If you have setup to use a delay buffer this allows you to control the length of the buffered data.
• Init IO Disable Duration: For motor controls it often takes a moment for a neural control node to stabilize so it is ready to start being used once the sim first starts. This allows you to disable any output from this adapter for a specific period of time when the simulation first starts. This gives your control neurons time to stabilize.
• Target Data Type: This is a new adapter feature that allows you to choose the data type we are targeting on the output side. You now have several different types of motor control options. Previously, you could use velocity or servo (position). So you could control the velocity of the motor or the position of the motor, but not both. You now have Position and velocity, and you can use the target data type to specify which one this adapter is targeting. This allows you to have two adapters onto the same motor, with one controlling the position and another controlling the velocity.
• Robot IO Scale: This is a scaling factor applied to the output value during simulations. The exact value of inputs may not match the simulation perfectly and this lets you scale it to match more closely.
• Synch With Robot: This lets you override the Synch setting on the robot interface. So if you want all the adapters except this one to synch the simulation you can turn that option off for this adapter.
• Synch Update Interval: If you have a robot interface and you have set it to Synch Simulation, then this lets you control the synch update interval for this specific adapter. For example, if it takes 2 ms to update a given motor, and there are 3 motors in the system, then we will only be able to update the info on that motor every 6 ms max. This allows you to specify how often you could get data back to make your sim more closely match the real hardware.
• Synch Update Start Interval: This allows you to specify how long after the simulation has started before synching starts.

Please see the video tutorials for a hands-on example of how you use these features. Once you have the robot interface setup you can add your IO interfaces.