Talk:Robotic Battlefield Control - Revision history

AndreaSalvi: /* Related files and pages */

2013-01-08T10:22:04Z

‎Related files and pages

AndreaSalvi: /* ArchLinux */

2012-09-06T07:59:14Z

‎ArchLinux

AndreaSalvi at 07:58, 6 September 2012

2012-09-06T07:58:52Z

AndreaSalvi at 16:51, 5 September 2012

2012-09-05T16:51:46Z

AndreaSalvi: /* Useful and interesting links */

2012-09-05T09:35:36Z

‎Useful and interesting links

AndreaSalvi: /* Frameworks, Libraries, etc. */

2012-09-03T15:18:33Z

‎Frameworks, Libraries, etc.

AndreaSalvi: /* Useful and interesting links */

2012-09-03T14:46:50Z

‎Useful and interesting links

AndreaSalvi: Link to the state diagrams file inserted.

2012-09-03T13:31:44Z

Link to the state diagrams file inserted.

AndreaSalvi: /* Useful and interesting links */

2012-07-22T13:33:29Z

‎Useful and interesting links

AndreaSalvi: Created page with "== 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 auto..."

2012-07-21T16:36:49Z

Created page with "== 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 auto..."

New page

== 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.

== "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 ==
* [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.

@@ Line 1: / Line 1: @@
-== Related files ==
+== Related files and pages ==
 * [[File:RBC_state_diagrams.pdf‎]]
 == Playfield geometry ==

@@ Line 46: / Line 46: @@
 ==== 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].
+[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 ====

@@ Line 37: / Line 37: @@
 * '''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 ==
@@ Line 48: / Line 45: @@
 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.
 == Useful and interesting links ==

@@ Line 50: / Line 50: @@
 ** [http://www.mrpt.org/Tutorials Tutorials and guides]
 ** [http://www.mrpt.org/downloads/mrpt-book.pdf Reference Guide]
 * [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.

@@ Line 44: / Line 44: @@
 === 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++
+* [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://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

@@ Line 40: / Line 40: @@
 * "Reachable map" concept
 * Planning movement through the identification of landmarks (the home field and the control point).
 == Useful and interesting links ==

← Older revision		Revision as of 14:46, 3 September 2012
Line 42:		Line 42:

	== Useful and interesting links ==		== 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++
		+	* [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.
		+	* [http://www.mrpt.org Mobile Robot Programming Toolkit]: a C++ based framework for SLAM-based navigation, compatible with Linux and Windows.
		+
		+	=== 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://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

← Older revision		Revision as of 13:31, 3 September 2012
Line 1:		Line 1:
		+	== Related files ==
		+	* [[File:RBC_state_diagrams.pdf‎]]
		+
	== Playfield geometry ==		== Playfield geometry ==
	The playfield is divided into three parts:		The playfield is divided into three parts:

← Older revision		Revision as of 13:33, 22 July 2012
Line 39:		Line 39:

	== Useful and interesting links ==		== Useful and interesting links ==
−	* [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://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.