View source for Talk:Robotic Battlefield Control

== Related files and pages ==
* [[File:RBC_state_diagrams.pdf‎]]
* [[Cross-compiling_for_the_RaspberryPi | How to setup a cross-compiling environment for the RasPi]]

== Playfield geometry ==
The playfield is divided into three parts:
* two '''home fields''' (one for each player), colored in blue for the human player and in red for the autonomous robot. The robots begin a match in these fields, and they are invulnerable while they are inside them; moreover, while being inside of these areas, they will be automatically "repaired" of any damage that they have might suffered during the match. If a robot is severely damaged during fights, it will switch to an "emergency mode" that will force it to head back home for repairs.
* the '''midfield''', where the '''control point''' is also located. The midfield can be cluttered with obstacles of various nature.

== Hardware Platforms ==

=== Remotely controlled robot ===
The user-controlled robot will be based on the [http://www.spykeeworld.com/spykee/UK/index.html Spykee] platform, which features a reprogrammable Linux-based firmware, and has a frontal camera and a monodirectional microphone as main sensors. Spykee will be controlled through an Android-based program (for smartphones and tablets) which will also function as the setup application for the game itself.

The robot will be also be "dressed" in blue on all sides, in order to be recognizable by the autonomous robot.

----
=== Autonomous robot ===
As for the remotely-controlled robot, the autonomous robot will be colored (in red) in order to be easily recognizeable.
==== Software Architecture ====
In order to keep the architecture as light as possible, a subsumption architecture, enhanced with obstacle maps ([[#Pending further analysis|see below]]).

==== Sensors ====
* An '''omni-directional microphone''': to sense the vicinity and the probable position of the remotely controlled robot, and to hear the beeper indicating the position of the control point.
* A '''frontal camera''', which is able to recognize arbitrarily shaped objects (blobs) of a certain color, and returns the coordinates of the vertices of the rectangles that enclose them at no additional cost for the main microcontroller/CPU. This is used:
** to recognize the "home fields" locations;
** to have a visual confirmation of the presence of the control point;
** to identify the remotely controlled robot.
* '''Proximity sensors''' on all sides of the robot, to understand if there are obstacles nearby. To avoid a too coarse identification of obstacles (that would rule out viable passages for the robot), different kind of sensors can be used: for example, ultrasound sonar sensors for coarse detection and infrared sensors for a more fine-grained sensing.

==== Pending further analysis ====
* '''Odometry''': since we have decided to keep an "explorable map" (that is, the map of the explored world, with reasonable metrical errors) in memory, it is imperative to find an economic and simple way to track odometry. It doesn't have to be extremely accurate, but it needs to be accurate enough so that maps don't have to be recalculated from scratch in the middle of a match. Use encoders on wheels?
* '''Hardware architecture''': [http://www.arduino.cc Arduino]-like or ARM based? ARM based boards (like the [http://www.raspberrypi.org RaspberryPi]) are more expensive but also more powerful, and can run libraries like OpenCV. In case of non-availability of ARM-based boards it is possible to use nano-ITX or pico-ITX x86 boards.

==== To be discussed ====
* '''Compass''': a compass might be useful for the robot, in order to know its orientation in the world. Is it also possible to add it to Spykee?
* '''Mobile robot type''': Wheeled with differential drive? Synchronous drive? With tracks?
* '''Tactical AI''': How to implement it? We want the robot's reactions to be as responsive and believable as possible, since the aim of the game is to entertain the user with a challenge.


== Implementation ==

=== Operating System ===

==== Debian 6.0 "Squeeze" ====
If we are going to use Debian 6.0 as the "backbone" of our robot, and if we are going to use MRPT (see below) and all its features, then we must compile many libraries by hand, including MRPT itself, [http://www.vtk.org/ VTK], [http://eigen.tuxfamily.org/index.php?title=Main_Page Eigen], [http://pointclouds.org/ Point Cloud Library] and their dependencies. It can be quite a chore.

==== ArchLinux ====
[http://www.archlinux.org/ The distro] follows a rolling release model (like Gentoo, but with precompiled and optimized packages), so all system packages are always up to date. This shortens compilation time '''a lot'''. Like Debian 6.0, it also supports the RaspberryPi through the ARM port [http://archlinuxarm.org/platforms/armv6/raspberry-pi ArchLinux ARM].

==== Ubuntu 12.04 LTS ====
Ongoing testing.


== "Strong" themes for the thesis ==
* "Reachable map" concept
* Planning movement through the identification of landmarks (the home field and the control point).

== Useful and interesting links ==

=== Frameworks, Libraries, etc. ===
* [http://eris.liralab.it/yarp/ YARP, Yet Another Robot Platform]: lightweight opensource robot platform, compatible with Linux, Windows and Mac, written in C++. It is first and foremost a middleware aimed to create an actual robot software platform, rather than being an integrated, all-inclusive environment per se.
** [http://eris.liralab.it/yarpdoc/index.html Documentation]

* [http://www.mrpt.org Mobile Robot Programming Toolkit]: a C++ based framework. compatible with Linux and Windows. It seems much more complete than YARP, and it prominently features libraries aimed to SLAM-based navigation.
** [http://www.mrpt.org/Tutorials Tutorials and guides]
** [http://www.mrpt.org/downloads/mrpt-book.pdf Reference Guide]
** [http://www.youtube.com/watch?v=IHGcW_DCaps] Video about a demonstration of SLAM navigation done through MRPT.

* [http://www.urbiforge.org/ URBI]: another opensource robot platform, but probably heavy on the CPU. It features a reusable library of modules written in C++, an orchestration/scripting language and compatibility with ROS modules.

=== Papers ===
* [http://www.robots.ox.ac.uk/~lav/Papers/davison_etal_pami2007/davison_etal_pami2007.pdf MonoSLAM]: paper about the single-camera Simultaneous Localization And Mapping algorithm.
* [http://geology.heroy.smu.edu/~dpa-www/robo/subsumption/]: notes about implementing a subsumption architecture in plain C