Sbot Common Interface
What is the common interface, and why should we use it?
- Write Controller Once, instead of modifying for each platform.
- Save time - no code rewrites. Maintain just one version of your code
- When developing in simulation, you can do frequent reality checks on real robots.
- Everyone shares a common build environment. We can stop reinventing the wheel.
- All controllers stored in common repository. Can easily browse other people's code.
- Share and jointly improve tools - eg. scripts for copying files to sbots
- All extra libraries included in common interface - toolchain, sboteyelib etc.
Common Interface QuickStart
- Install subversion.
- apt-get install subversion
- Checkout common interface from repository
- svn checkout svn+ssh://<your iridia username>@iridia.ulb.ac.be/usr/local/share/svn_repositories/sbotci
- Compile one of the example controllers for the real robot
- cd sbotci/real_sbot
- ./build_scripts/build_support_libs.sh (build toolchain, sboteyelib etc)
- make controller=describe_circle
- Copy binary to sbot and run it
- ./tools/sbot_file_copy/copy_binary_to_sbot.sh describe_circle <sbot number>
- ssh root@sbot<sbotnumber>
- cd /tmp
- Compile twodee and run an example controller
- cd sbotci/twodee
- ./twodee -e10003 --experiment-parameters controller=describe_circle
Write your own common interface controller
You will need to familiarise yourself with the basics of source code control using svn. If you are already familiar with cvs this is a piece of cake, as svn commands are by in large a superset of cvs commands.
When you write your common interface controller, you basically have to implement three functions
Everything else is done for you.
Your code needs to live in the directory sbotci/controllers/<your_name>/<controllername>
If these directories do not exist you will have to create them and add them to svn with the svn add command.
The easiest way to get started is probable to copy one of the examples in the sbotci/controllers/generic directory into your own directory ( sbotci/controllers/<your_name>/ )/
- cd sbotci/controllers/<your_name>
- cp -r ../describe_circle ./my_test_controller
- To compile your controller on the real sbot
- cd sbotci/real_sbot
- make controller=my_test_controller
- To compile your controller in twodee
- Anders - can you fill this in. Thx.
How to make your simulator compatible with the common interface
In order to implement the common interface for another simulator, you need to implement the common s-bot interface, the sensor factory and any sensors that can be made compatible with your simulator (or that you can be bothered implementing). The s-sbot common interface, which consists of the set of methods through which an s-bot is controlled, does not need to be fully implemented. To start off you might only implement the method, which sets the speed of the treels. This will allow you to run for instance the describe_circle behavior. For more elaborate controllers using sensors and other actuators you will of course have to implement the corresponding methods of the s-bot interface.
The s-bot common interface
The s-bot common interface is a super class specificing the interface. For the real s-bots specialization, all methods have been implemented so that the s-bot API is called, while in TwoDee another specialization in which the simulated robots are controlled instead.
// Super class implementation: // Real s-bot implementation: // TwoDee implementation:
The sensor factory common interface
The sensor factory allows for implementing complex sensors, like the camera, in simulators. The sensor factory is a class, which controllers can ask to create instances of sensors.
How the common interface was implemented in TwoDee
In TwoDee the common-interface is really just a controller like every other controller. Whenever a common interface controller writes actuator outputs to the s-bot common interface, the TwoDee implementation translates the calls to control the simulated s-bot. Likewise, when a common interface controller reads the state of a sensor, TwoDee queries the corresponding simulated sensor and translates whatever input/output to the appropriate units.