AIRWiki - User contributions [en]

Cross-compiling for the RaspberryPi

2013-05-25T15:47:15Z

AndreaSalvi: Prerequisites: added a missing library for Debian.

This page will guide you to setup a complete cross-compiling environment for the [http://raspberrypi.org RaspberryPi] board. This procedure is tailored for and tested on Ubuntu 12.10, but it can be easily adapted for the use on other distributions.

== Prerequisites ==
* Install all the required software packages:
<code>sudo apt-get install git rsync cmake</code>

* '''If you are using a 64-bit version of Ubuntu''', also install the 32-bit compatibility libraries:
<code>sudo apt-get install ia32-libs</code>

* '''If you are using a 64-bit version of Debian''', the ia32-libs metapackage is no longer installable. Execute instead
<code>su -
dpkg --add-architecture i386
apt-get update && apt-get install libc6-i386 lib32stdc++6 zlib1g:i386</code>

* The guide will take for granted that you are using the official Raspbian OS image, downloadable from the RaspberryPi website.
* Moreover, you will need a working SSH connection between the Raspberry and your computer (not covered by this guide).

== Step One: installing the cross-compiler ==

* Select a directory in which you will install everything. For the purposes of this guide, I will consider a subdirectory of your home folder, <code>~/raspberrypi</code> . Create it and then access it:
<code>cd
mkdir raspberrypi
cd raspberrypi</code>

* Download the "official" cross-compiler of the Raspberry Pi project through <code>git</code>:
<code>git clone git://github.com/raspberrypi/tools.git</code>
This will create, among other things, a <code>tools/arm-bcm2708</code> subfolder containing three different compiler toolchains:

arm-bcm2708-linux-gnueabi

arm-bcm2708hardfp-linux-gnueabi

gcc-linaro-arm-linux-gnueabihf-raspbian

We are going to use the third of these toolchains, since it's the most optimized and supports the FPU that is available on the RaspberryPi board.

* Go back to your home directory, and open your <code>.bashrc</code> configuration file with any text editor, like <code>nano</code>, <code>gedit</code> or <code>leafpad</code>, and add this string at the bottom:
<code>PATH=$PATH:$HOME/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin</code>

* Now, either logout and login back again, or just close and reopen the terminal window, and type:
<code>arm-linux-gnueabihf-gcc -v</code>
If all goes well, you should see something like
<code>tudhalyas@gondor:~$ arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/home/tudhalyas/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../libexec/gcc/arm-linux-gnueabihf/4.7.2/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: /cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/src/gcc-linaro-4.7-2012.08/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=arm-linux-gnueabihf --prefix=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/install --with-sysroot=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/install/arm-linux-gnueabihf/libc --enable-languages=c,c++,fortran --disable-multilib --with-arch=armv6 --with-tune=arm1176jz-s --with-fpu=vfp --with-float=hard --with-pkgversion='crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08' --with-bugurl=https://bugs.launchpad.net/gcc-linaro --enable-__cxa_atexit --enable-libmudflap --enable-libgomp --enable-libssp --with-gmp=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-mpfr=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-mpc=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-ppl=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-cloog=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-libelf=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-host-libstdcxx='-L/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static/lib -lpwl' --enable-threads=posix --disable-libstdcxx-pch --enable-linker-build-id --enable-plugin --enable-gold --with-local-prefix=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/install/arm-linux-gnueabihf/libc --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.7.2 20120731 (prerelease) (crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08)</code>

== Step Two: set-up your compiling environment ==

* Go back into the <code>raspberrypi</code> directory and create a subfolder named <code>rootfs</code>:
<code>cd
cd raspberrypi
mkdir rootfs</code>
* Now tell <code>rsync</code> to copy the entirety of the <code>/usr</code> and <code>/lib</code> directories of your RaspberryPi filesystem into the newly created folder on your computer:
<code>rsync -rl --delete-after --safe-links pi@$RASPI:/{lib,usr} $HOME/raspberrypi/rootfs</code>
where <code>$RASPI</code> is the IP address of the Raspberry. You can put this line of code in a text file and save it as a shell script for your convenience.
* Create a text file called <code>Toolchain-RaspberryPi.cmake</code> and insert the following into it:

SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 1)
# specify the cross compiler
SET(CMAKE_C_COMPILER $ENV{HOME}/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc)
SET(CMAKE_CXX_COMPILER $ENV{HOME}/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-g++)
# where is the target environment
SET(CMAKE_FIND_ROOT_PATH $ENV{HOME}/raspberrypi/rootfs)
# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

* Now you are able to compile your own projects using <code>cmake</code>, by passing the path of the Toolchain specification file to the program (supposing that the sources are located into a <code>src</code> directory which in turn is located into <code>${PROJECT_DIR}</code>):
<code>mkdir ${PROJECT_DIR}/build
cd ${PROJECT_DIR}/build
cmake -G"Eclipse CDT4 - Unix Makefiles" -D CMAKE_BUILD_TYPE=Debug -D CMAKE_TOOLCHAIN_FILE=$HOME/raspberrypi/Toolchain-RaspberryPi.cmake ../src</code>

== Step Three: Remote program execution through Eclipse ==

... to be continued ...

== References ==
* http://wiki.debian.org/Multiarch/HOWTO
* http://hertaville.com/2012/09/28/development-environment-raspberry-pi-cross-compiler/
* http://www.kitware.com/blog/home/post/426
* http://www.cmake.org/Wiki/CMake_Cross_Compiling

Cross-compiling for the RaspberryPi

2013-05-24T16:39:52Z

AndreaSalvi: References: added link to Debian wiki's Multiarch article

This page will guide you to setup a complete cross-compiling environment for the [http://raspberrypi.org RaspberryPi] board. This procedure is tailored for and tested on Ubuntu 12.10, but it can be easily adapted for the use on other distributions.

== Prerequisites ==
* Install all the required software packages:
<code>sudo apt-get install git rsync cmake</code>

* '''If you are using a 64-bit version of Ubuntu''', also install the 32-bit compatibility libraries:
<code>sudo apt-get install ia32-libs</code>

* '''If you are using a 64-bit version of Debian''', the ia32-libs metapackage is no longer installable. Execute instead
<code>su -
dpkg --add-architecture i386
apt-get update && apt-get install libc6-i386 lib32stdc++6</code>

* The guide will take for granted that you are using the official Raspbian OS image, downloadable from the RaspberryPi website.
* Moreover, you will need a working SSH connection between the Raspberry and your computer (not covered by this guide).

== Step One: installing the cross-compiler ==

* Select a directory in which you will install everything. For the purposes of this guide, I will consider a subdirectory of your home folder, <code>~/raspberrypi</code> . Create it and then access it:
<code>cd
mkdir raspberrypi
cd raspberrypi</code>

* Download the "official" cross-compiler of the Raspberry Pi project through <code>git</code>:
<code>git clone git://github.com/raspberrypi/tools.git</code>
This will create, among other things, a <code>tools/arm-bcm2708</code> subfolder containing three different compiler toolchains:

arm-bcm2708-linux-gnueabi

arm-bcm2708hardfp-linux-gnueabi

gcc-linaro-arm-linux-gnueabihf-raspbian

We are going to use the third of these toolchains, since it's the most optimized and supports the FPU that is available on the RaspberryPi board.

* Go back to your home directory, and open your <code>.bashrc</code> configuration file with any text editor, like <code>nano</code>, <code>gedit</code> or <code>leafpad</code>, and add this string at the bottom:
<code>PATH=$PATH:$HOME/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin</code>

* Now, either logout and login back again, or just close and reopen the terminal window, and type:
<code>arm-linux-gnueabihf-gcc -v</code>
If all goes well, you should see something like
<code>tudhalyas@gondor:~$ arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/home/tudhalyas/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../libexec/gcc/arm-linux-gnueabihf/4.7.2/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: /cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/src/gcc-linaro-4.7-2012.08/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=arm-linux-gnueabihf --prefix=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/install --with-sysroot=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/install/arm-linux-gnueabihf/libc --enable-languages=c,c++,fortran --disable-multilib --with-arch=armv6 --with-tune=arm1176jz-s --with-fpu=vfp --with-float=hard --with-pkgversion='crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08' --with-bugurl=https://bugs.launchpad.net/gcc-linaro --enable-__cxa_atexit --enable-libmudflap --enable-libgomp --enable-libssp --with-gmp=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-mpfr=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-mpc=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-ppl=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-cloog=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-libelf=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-host-libstdcxx='-L/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static/lib -lpwl' --enable-threads=posix --disable-libstdcxx-pch --enable-linker-build-id --enable-plugin --enable-gold --with-local-prefix=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/install/arm-linux-gnueabihf/libc --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.7.2 20120731 (prerelease) (crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08)</code>

== Step Two: set-up your compiling environment ==

* Go back into the <code>raspberrypi</code> directory and create a subfolder named <code>rootfs</code>:
<code>cd
cd raspberrypi
mkdir rootfs</code>
* Now tell <code>rsync</code> to copy the entirety of the <code>/usr</code> and <code>/lib</code> directories of your RaspberryPi filesystem into the newly created folder on your computer:
<code>rsync -rl --delete-after --safe-links pi@$RASPI:/{lib,usr} $HOME/raspberrypi/rootfs</code>
where <code>$RASPI</code> is the IP address of the Raspberry. You can put this line of code in a text file and save it as a shell script for your convenience.
* Create a text file called <code>Toolchain-RaspberryPi.cmake</code> and insert the following into it:

SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 1)
# specify the cross compiler
SET(CMAKE_C_COMPILER $ENV{HOME}/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc)
SET(CMAKE_CXX_COMPILER $ENV{HOME}/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-g++)
# where is the target environment
SET(CMAKE_FIND_ROOT_PATH $ENV{HOME}/raspberrypi/rootfs)
# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

* Now you are able to compile your own projects using <code>cmake</code>, by passing the path of the Toolchain specification file to the program (supposing that the sources are located into a <code>src</code> directory which in turn is located into <code>${PROJECT_DIR}</code>):
<code>mkdir ${PROJECT_DIR}/build
cd ${PROJECT_DIR}/build
cmake -G"Eclipse CDT4 - Unix Makefiles" -D CMAKE_BUILD_TYPE=Debug -D CMAKE_TOOLCHAIN_FILE=$HOME/raspberrypi/Toolchain-RaspberryPi.cmake ../src</code>

== Step Three: Remote program execution through Eclipse ==

... to be continued ...

== References ==
* http://wiki.debian.org/Multiarch/HOWTO
* http://hertaville.com/2012/09/28/development-environment-raspberry-pi-cross-compiler/
* http://www.kitware.com/blog/home/post/426
* http://www.cmake.org/Wiki/CMake_Cross_Compiling

Cross-compiling for the RaspberryPi

2013-05-24T16:38:38Z

AndreaSalvi: Prerequisites: added information about Debian.

This page will guide you to setup a complete cross-compiling environment for the [http://raspberrypi.org RaspberryPi] board. This procedure is tailored for and tested on Ubuntu 12.10, but it can be easily adapted for the use on other distributions.

== Prerequisites ==
* Install all the required software packages:
<code>sudo apt-get install git rsync cmake</code>

* '''If you are using a 64-bit version of Ubuntu''', also install the 32-bit compatibility libraries:
<code>sudo apt-get install ia32-libs</code>

* '''If you are using a 64-bit version of Debian''', the ia32-libs metapackage is no longer installable. Execute instead
<code>su -
dpkg --add-architecture i386
apt-get update && apt-get install libc6-i386 lib32stdc++6</code>

* The guide will take for granted that you are using the official Raspbian OS image, downloadable from the RaspberryPi website.
* Moreover, you will need a working SSH connection between the Raspberry and your computer (not covered by this guide).

== Step One: installing the cross-compiler ==

* Select a directory in which you will install everything. For the purposes of this guide, I will consider a subdirectory of your home folder, <code>~/raspberrypi</code> . Create it and then access it:
<code>cd
mkdir raspberrypi
cd raspberrypi</code>

* Download the "official" cross-compiler of the Raspberry Pi project through <code>git</code>:
<code>git clone git://github.com/raspberrypi/tools.git</code>
This will create, among other things, a <code>tools/arm-bcm2708</code> subfolder containing three different compiler toolchains:

arm-bcm2708-linux-gnueabi

arm-bcm2708hardfp-linux-gnueabi

gcc-linaro-arm-linux-gnueabihf-raspbian

We are going to use the third of these toolchains, since it's the most optimized and supports the FPU that is available on the RaspberryPi board.

* Go back to your home directory, and open your <code>.bashrc</code> configuration file with any text editor, like <code>nano</code>, <code>gedit</code> or <code>leafpad</code>, and add this string at the bottom:
<code>PATH=$PATH:$HOME/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin</code>

* Now, either logout and login back again, or just close and reopen the terminal window, and type:
<code>arm-linux-gnueabihf-gcc -v</code>
If all goes well, you should see something like
<code>tudhalyas@gondor:~$ arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/home/tudhalyas/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../libexec/gcc/arm-linux-gnueabihf/4.7.2/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: /cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/src/gcc-linaro-4.7-2012.08/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=arm-linux-gnueabihf --prefix=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/install --with-sysroot=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/install/arm-linux-gnueabihf/libc --enable-languages=c,c++,fortran --disable-multilib --with-arch=armv6 --with-tune=arm1176jz-s --with-fpu=vfp --with-float=hard --with-pkgversion='crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08' --with-bugurl=https://bugs.launchpad.net/gcc-linaro --enable-__cxa_atexit --enable-libmudflap --enable-libgomp --enable-libssp --with-gmp=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-mpfr=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-mpc=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-ppl=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-cloog=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-libelf=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-host-libstdcxx='-L/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static/lib -lpwl' --enable-threads=posix --disable-libstdcxx-pch --enable-linker-build-id --enable-plugin --enable-gold --with-local-prefix=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/install/arm-linux-gnueabihf/libc --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.7.2 20120731 (prerelease) (crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08)</code>

== Step Two: set-up your compiling environment ==

* Go back into the <code>raspberrypi</code> directory and create a subfolder named <code>rootfs</code>:
<code>cd
cd raspberrypi
mkdir rootfs</code>
* Now tell <code>rsync</code> to copy the entirety of the <code>/usr</code> and <code>/lib</code> directories of your RaspberryPi filesystem into the newly created folder on your computer:
<code>rsync -rl --delete-after --safe-links pi@$RASPI:/{lib,usr} $HOME/raspberrypi/rootfs</code>
where <code>$RASPI</code> is the IP address of the Raspberry. You can put this line of code in a text file and save it as a shell script for your convenience.
* Create a text file called <code>Toolchain-RaspberryPi.cmake</code> and insert the following into it:

SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 1)
# specify the cross compiler
SET(CMAKE_C_COMPILER $ENV{HOME}/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc)
SET(CMAKE_CXX_COMPILER $ENV{HOME}/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-g++)
# where is the target environment
SET(CMAKE_FIND_ROOT_PATH $ENV{HOME}/raspberrypi/rootfs)
# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

* Now you are able to compile your own projects using <code>cmake</code>, by passing the path of the Toolchain specification file to the program (supposing that the sources are located into a <code>src</code> directory which in turn is located into <code>${PROJECT_DIR}</code>):
<code>mkdir ${PROJECT_DIR}/build
cd ${PROJECT_DIR}/build
cmake -G"Eclipse CDT4 - Unix Makefiles" -D CMAKE_BUILD_TYPE=Debug -D CMAKE_TOOLCHAIN_FILE=$HOME/raspberrypi/Toolchain-RaspberryPi.cmake ../src</code>

== Step Three: Remote program execution through Eclipse ==

... to be continued ...

== References ==
* http://hertaville.com/2012/09/28/development-environment-raspberry-pi-cross-compiler/
* http://www.kitware.com/blog/home/post/426
* http://www.cmake.org/Wiki/CMake_Cross_Compiling

ODROID

2013-05-20T17:50:09Z

AndreaSalvi: /* Tested OS and versions */

There are two [http://www.hardkernel.com/ ODROID] U2 for development of small robots. Here are details and suggestions for their use.

=== Useful How-Tos ===
* [http://forum.odroid.com/viewtopic.php?f=52&t=81 Kernel recompiling process for the ODROID-U2]; it is necessary to do this if you ever wish to install external/out-of-tree drivers, as the "official package" is missing several critical kernel headers.

=== Tested OS and versions ===
* [http://forum.odroid.com/viewtopic.php?f=8&t=1193 Xubuntu 13.04] for armhf architectures, released by HardKernel with their [https://github.com/hardkernel/linux modified Linux kernel, version 3.0.75]. The kernel can be recompiled for using 3D video acceleration but this would prevent USB video cameras to work, so it's useless for robot development (even more so since OpenCL can't be even used).
* [http://forum.odroid.com/viewtopic.php?f=8&t=12 Linaro Ubuntu 12.11] with HardKernel's Linux kernel, version 3.0.60. Grab [http://dn.odroid.com/Ubuntu_U2/20130125/ this image] dated 25-01-2013, flash it on your microSD card and then apply the latest point kernel point update (at the time of writing, it is version 3.0.63, dated 13-02-2013) following the instructions given on the thread's opening post.

'''All OSes have wireless networking issues, please read below for more information.'''

=== Tested I/O devices ===

==== Monitors ====
Monitors need a native HDMI interface to work with ODROIDs due to the strict requirements of the Exynos system-on-chip; for the same reason, external HDMI-to-DVI adapters are also '''not''' recommended, as you could result having a blank image screen ([http://odroid.us/mediawiki/index.php?title=Troubleshooting#My_Device_boots_.28The_alive_led_blinks.29.2C_but_it_doesnt_show_anything_on_the_display source] )

This is a list of monitors and TV screens with native HDMI ports that are known to work.
* Sony KDL-32V4500
* Samsung Syncmaster XL2370 HD

=== Tested wireless communication ===

=== Tested wired communication ===

=== Unresolved issues ===

==== Wireless Networking (all tested OSes) ====
Wireless communications seem to be very troublesome, as the network interfaces tend to lose or drop a lot of packages, both in RX and TX, to the point that a reliable SSH connection cannot be established. This happens at least with the "officially supported" wireless NIC (with a Realtek RTL8191SU chipset), even if the wifi signal strength is excellent.

A curious aspect of this issue is that only incoming packets get dropped a lot, while outgoing packets are very modestly affected.

This being said, the RTL8191SU adapter loses some packets along the way also while being connected to other computers, so maybe it's really not the best USB wifi adapter ''ever''.

root@odroid:~# ifconfig wlan6
wlan6 Link encap:Ethernet HWaddr **:**:**:**:**:**
inet addr:192.168.1.60 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::ee1a:59ff:fe0e:f122/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:453 errors:0 dropped:600 overruns:0 frame:0
TX packets:292 errors:0 dropped:7 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:79264 (79.2 KB) TX bytes:35116 (35.1 KB)

odroid@odroid:~$ iwconfig wlan6
wlan6 IEEE 802.11bg ESSID:"MyWirelessNet" Nickname:"<WIFI@REALTEK>"
Mode:Managed Frequency:2.437 GHz Access Point: **:**:**:**:**:**
Bit Rate:54 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Encryption key:****-****-****-****-****-****-****-**** Security mode:open
Power Management:off
Link Quality=100/100 Signal level=100/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

===== Realtek RTL8192CU =====
This chipset seems not to be even detected by the stock HK kernel (all versions of it), but it is possible to use it after recompiling the kernel, disabling the in-kernel module for the NIC, and integrating [http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=21&PFid=48&Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true Realtek's official driver] for this chipset inside it (instructions are included in the package).

However, you still get a huge packet loss rate, even if you disable the power saving feature of the driver by loading the kernel module with
sudo modprobe 8192cu rtw_power_mgnt=0

=== Solved issues ===

==== lshw glitches (all tested OSes) ====
With the stock kernel the lshw command seems to be partly broken, but this is resolved by calling it with
sudo lshw -disable dmi
although this will prevent the detection of certain features of the board. Another way of fixing this issue is to recompile the kernel by hand (see the how-to linked above).

ODROID

2013-05-20T17:46:19Z

AndreaSalvi: Added Linaro Ubuntu 12.11; moved the issues Section below.

There are two [http://www.hardkernel.com/ ODROID] U2 for development of small robots. Here are details and suggestions for their use.

=== Useful How-Tos ===
* [http://forum.odroid.com/viewtopic.php?f=52&t=81 Kernel recompiling process for the ODROID-U2]; it is necessary to do this if you ever wish to install external/out-of-tree drivers, as the "official package" is missing several critical kernel headers.

=== Tested OS and versions ===
* [http://forum.odroid.com/viewtopic.php?f=8&t=1193 Xubuntu 13.04] for armhf architectures, released by HardKernel with their [https://github.com/hardkernel/linux modified Linux kernel, version 3.0.75]. The kernel can be recompiled for using 3D video acceleration but this would prevent USB video cameras to work, so it's useless for robot development (even more so since OpenCL can't be even used).
* [http://forum.odroid.com/viewtopic.php?f=8&t=12 Linaro Ubuntu 12.11] with HardKernel's Linux kernel, version 3.0.60. Grab [http://dn.odroid.com/Ubuntu_U2/20130125/ this image] dated 25-01-2013 and then apply the latest point kernel point update (at the time of writing, it is version 3.0.63, dated 13-02-2013) following the instructions given on the thread's opening post.

'''All OSes have wireless networking issues, please read below for more information.'''

=== Tested I/O devices ===

==== Monitors ====
Monitors need a native HDMI interface to work with ODROIDs due to the strict requirements of the Exynos system-on-chip; for the same reason, external HDMI-to-DVI adapters are also '''not''' recommended, as you could result having a blank image screen ([http://odroid.us/mediawiki/index.php?title=Troubleshooting#My_Device_boots_.28The_alive_led_blinks.29.2C_but_it_doesnt_show_anything_on_the_display source] )

This is a list of monitors and TV screens with native HDMI ports that are known to work.
* Sony KDL-32V4500
* Samsung Syncmaster XL2370 HD

=== Tested wireless communication ===

=== Tested wired communication ===

=== Unresolved issues ===

==== Wireless Networking (all tested OSes) ====
Wireless communications seem to be very troublesome, as the network interfaces tend to lose or drop a lot of packages, both in RX and TX, to the point that a reliable SSH connection cannot be established. This happens at least with the "officially supported" wireless NIC (with a Realtek RTL8191SU chipset), even if the wifi signal strength is excellent.

A curious aspect of this issue is that only incoming packets get dropped a lot, while outgoing packets are very modestly affected.

This being said, the RTL8191SU adapter loses some packets along the way also while being connected to other computers, so maybe it's really not the best USB wifi adapter ''ever''.

root@odroid:~# ifconfig wlan6
wlan6 Link encap:Ethernet HWaddr **:**:**:**:**:**
inet addr:192.168.1.60 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::ee1a:59ff:fe0e:f122/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:453 errors:0 dropped:600 overruns:0 frame:0
TX packets:292 errors:0 dropped:7 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:79264 (79.2 KB) TX bytes:35116 (35.1 KB)

odroid@odroid:~$ iwconfig wlan6
wlan6 IEEE 802.11bg ESSID:"MyWirelessNet" Nickname:"<WIFI@REALTEK>"
Mode:Managed Frequency:2.437 GHz Access Point: **:**:**:**:**:**
Bit Rate:54 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Encryption key:****-****-****-****-****-****-****-**** Security mode:open
Power Management:off
Link Quality=100/100 Signal level=100/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

===== Realtek RTL8192CU =====
This chipset seems not to be even detected by the stock HK kernel (all versions of it), but it is possible to use it after recompiling the kernel, disabling the in-kernel module for the NIC, and integrating [http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=21&PFid=48&Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true Realtek's official driver] for this chipset inside it (instructions are included in the package).

However, you still get a huge packet loss rate, even if you disable the power saving feature of the driver by loading the kernel module with
sudo modprobe 8192cu rtw_power_mgnt=0

=== Solved issues ===

==== lshw glitches (all tested OSes) ====
With the stock kernel the lshw command seems to be partly broken, but this is resolved by calling it with
sudo lshw -disable dmi
although this will prevent the detection of certain features of the board. Another way of fixing this issue is to recompile the kernel by hand (see the how-to linked above).

ODROID

2013-05-19T17:14:43Z

AndreaSalvi: /* Unresolved issues */

There are two [http://www.hardkernel.com/ ODROID] U2 for development of small robots. Here are details and suggestions for their use.

=== Useful How-Tos ===
* [http://forum.odroid.com/viewtopic.php?f=52&t=81 Kernel recompiling process for the ODROID-U2]; it is necessary to do this if you ever wish to install external/out-of-tree drivers, as the "official package" is missing several critical kernel headers.

=== Unresolved issues ===

==== Wireless Networking ====
Wireless communications seem to be very troublesome, as the network interfaces tend to lose or drop a lot of packages, both in RX and TX, to the point that a reliable SSH connection cannot be established. This happens at least with the "officially supported" wireless NIC (with a Realtek RTL8191SU chipset), even if the wifi signal strength is excellent.

This being said, the RTL8191SU adapter loses some packets along the way also while being connected to other computers, so maybe it's really not the best USB wifi adapter ''ever''.

root@odroid:~# ifconfig wlan6
wlan6 Link encap:Ethernet HWaddr **:**:**:**:**:**
inet addr:192.168.1.60 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::ee1a:59ff:fe0e:f122/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:453 errors:0 dropped:600 overruns:0 frame:0
TX packets:292 errors:0 dropped:7 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:79264 (79.2 KB) TX bytes:35116 (35.1 KB)

odroid@odroid:~$ iwconfig wlan6
wlan6 IEEE 802.11bg ESSID:"MyWirelessNet" Nickname:"<WIFI@REALTEK>"
Mode:Managed Frequency:2.437 GHz Access Point: **:**:**:**:**:**
Bit Rate:54 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Encryption key:****-****-****-****-****-****-****-**** Security mode:open
Power Management:off
Link Quality=100/100 Signal level=100/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

===== Realtek RTL8192CU =====
This chipset seems not to be even detected by the stock HK kernel, but it is possible to use it after recompiling the kernel, disabling the in-kernel module for the NIC, and integrating [http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=21&PFid=48&Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true Realtek's official driver] for this chipset inside it (instructions are included in the package).

However, you still get a huge packet loss rate, even if you disable the power saving feature of the driver by loading the kernel module with
sudo modprobe 8192cu rtw_power_mgnt=0

=== Tested OS and versions ===
* [http://forum.odroid.com/viewtopic.php?f=8&t=1193 Xubuntu 13.04] for armhf architectures, released by HardKernel with their [https://github.com/hardkernel/linux modified Linux kernel, version 3.0.75]. The kernel can be recompiled for using 3D video acceleration but this would prevent USB video cameras to work, so it's useless for robot development (even more so since OpenCL can't be even used).
Note: in this version of the OS, the lshw command seems to be partly broken, but this is resolved by calling it with
sudo lshw -disable dmi
although this will prevent the detection of certain features of the board.

=== Tested I/O devices ===

==== Monitors ====
Monitors need a native HDMI interface to work with ODROIDs due to the strict requirements of the Exynos system-on-chip; for the same reason, external HDMI-to-DVI adapters are also '''not''' recommended, as you could result having a blank image screen ([http://odroid.us/mediawiki/index.php?title=Troubleshooting#My_Device_boots_.28The_alive_led_blinks.29.2C_but_it_doesnt_show_anything_on_the_display source] )

This is a list of monitors and TV screens with native HDMI ports that are known to work.
* Sony KDL-32V4500
* Samsung Syncmaster XL2370 HD

=== Tested wireless communication ===

=== Tested wired communication ===

ODROID

2013-05-19T16:50:58Z

AndreaSalvi: /* Wireless Networking */

There are two [http://www.hardkernel.com/ ODROID] U2 for development of small robots. Here are details and suggestions for their use.

=== Useful How-Tos ===
* [http://forum.odroid.com/viewtopic.php?f=52&t=81 Kernel recompiling process for the ODROID-U2]; it is necessary to do this if you ever wish to install external/out-of-tree drivers, as the "official package" is missing several critical kernel headers.

=== Unresolved issues ===

==== Wireless Networking ====
Wireless communications seem to be very troublesome, as the network interfaces tend to lose or drop a lot of packages, both in RX and TX, to the point that a reliable SSH connection cannot be established. This happens at least with the "officially supported" wireless NIC (with a Realtek RTL 8191SU chipset), even if the wifi signal strength is excellent.

root@odroid:~# ifconfig wlan6
wlan6 Link encap:Ethernet HWaddr **:**:**:**:**:**
inet addr:192.168.1.60 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::ee1a:59ff:fe0e:f122/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:453 errors:0 dropped:600 overruns:0 frame:0
TX packets:292 errors:0 dropped:7 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:79264 (79.2 KB) TX bytes:35116 (35.1 KB)

odroid@odroid:~$ iwconfig wlan6
wlan6 IEEE 802.11bg ESSID:"MyWirelessNet" Nickname:"<WIFI@REALTEK>"
Mode:Managed Frequency:2.437 GHz Access Point: **:**:**:**:**:**
Bit Rate:54 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Encryption key:****-****-****-****-****-****-****-**** Security mode:open
Power Management:off
Link Quality=100/100 Signal level=100/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

===== Realtek RTL8192CU =====
This chipset seems not to be even detected by the stock HK kernel, but it is possible to use it after recompiling the kernel, disabling the in-kernel module for the NIC, and integrating [http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=21&PFid=48&Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true Realtek's official driver] for this chipset inside it (instructions are included in the package).

However, you still get a huge packet loss rate, even if you disable the power saving feature of the driver by loading the kernel module with
sudo modprobe 8192cu rtw_power_mgnt=0

=== Tested OS and versions ===
* [http://forum.odroid.com/viewtopic.php?f=8&t=1193 Xubuntu 13.04] for armhf architectures, released by HardKernel with their [https://github.com/hardkernel/linux modified Linux kernel, version 3.0.75]. The kernel can be recompiled for using 3D video acceleration but this would prevent USB video cameras to work, so it's useless for robot development (even more so since OpenCL can't be even used).
Note: in this version of the OS, the lshw command seems to be partly broken, but this is resolved by calling it with
sudo lshw -disable dmi
although this will prevent the detection of certain features of the board.

=== Tested I/O devices ===

==== Monitors ====
Monitors need a native HDMI interface to work with ODROIDs due to the strict requirements of the Exynos system-on-chip; for the same reason, external HDMI-to-DVI adapters are also '''not''' recommended, as you could result having a blank image screen ([http://odroid.us/mediawiki/index.php?title=Troubleshooting#My_Device_boots_.28The_alive_led_blinks.29.2C_but_it_doesnt_show_anything_on_the_display source] )

This is a list of monitors and TV screens with native HDMI ports that are known to work.
* Sony KDL-32V4500
* Samsung Syncmaster XL2370 HD

=== Tested wireless communication ===

=== Tested wired communication ===

ODROID

2013-05-19T16:43:55Z

AndreaSalvi: /* Realtek RTL8192CU */

ODROID

2013-05-19T15:19:39Z

AndreaSalvi:

ODROID

2013-05-19T14:55:20Z

AndreaSalvi: /* Wireless Networking */

ODROID

2013-05-19T14:54:50Z

AndreaSalvi:

ODROID

2013-05-19T14:48:37Z

AndreaSalvi: Added new tested OS; added Unresolved Issues, How-Tos, and Monitors sections;

ODROID

2013-05-19T13:40:25Z

AndreaSalvi: AndreaSalvi moved page O-Droid to ODROID: The platform name was not correct.

There are two [http://www.hardkernel.com/ O-Droid] U-2 for development of small robots. Here are details and suggestions for their use.

==== Tested OS and versions ====

==== Tested I/O devices ====

==== Tested wireless communication ====

==== Tested wired communication ====

O-Droid

2013-05-19T13:40:25Z

AndreaSalvi: AndreaSalvi moved page O-Droid to ODROID: The platform name was not correct.

#REDIRECT [[ODROID]]

Cross-compiling for the RaspberryPi

2013-01-09T17:35:19Z

AndreaSalvi: Added the "Step Two" section

This page will guide you to setup a complete cross-compiling environment for the [http://raspberrypi.org RaspberryPi] board. This procedure is tailored for and tested on Ubuntu 12.10, but it can be easily adapted for the use on other distributions.

== Prerequisites ==
* Install all the required software packages:
<code>sudo apt-get install git rsync cmake</code>

* '''If you are using a 64-bit version of Ubuntu''', also install the 32-bit compatibility libraries:
<code>sudo apt-get install ia32-libs</code>

* The guide will take for granted that you are using the official Raspbian OS image, downloadable from the RaspberryPi website.
* Moreover, you will need a working SSH connection between the Raspberry and your computer (not covered by this guide).

== Step One: installing the cross-compiler ==

* Select a directory in which you will install everything. For the purposes of this guide, I will consider a subdirectory of your home folder, <code>~/raspberrypi</code> . Create it and then access it:
<code>cd
mkdir raspberrypi
cd raspberrypi</code>

* Download the "official" cross-compiler of the Raspberry Pi project through <code>git</code>:
<code>git clone git://github.com/raspberrypi/tools.git</code>
This will create, among other things, a <code>tools/arm-bcm2708</code> subfolder containing three different compiler toolchains:

arm-bcm2708-linux-gnueabi

arm-bcm2708hardfp-linux-gnueabi

gcc-linaro-arm-linux-gnueabihf-raspbian

We are going to use the third of these toolchains, since it's the most optimized and supports the FPU that is available on the RaspberryPi board.

* Go back to your home directory, and open your <code>.bashrc</code> configuration file with any text editor, like <code>nano</code>, <code>gedit</code> or <code>leafpad</code>, and add this string at the bottom:
<code>PATH=$PATH:$HOME/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin</code>

* Now, either logout and login back again, or just close and reopen the terminal window, and type:
<code>arm-linux-gnueabihf-gcc -v</code>
If all goes well, you should see something like
<code>tudhalyas@gondor:~$ arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/home/tudhalyas/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../libexec/gcc/arm-linux-gnueabihf/4.7.2/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: /cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/src/gcc-linaro-4.7-2012.08/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=arm-linux-gnueabihf --prefix=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/install --with-sysroot=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/install/arm-linux-gnueabihf/libc --enable-languages=c,c++,fortran --disable-multilib --with-arch=armv6 --with-tune=arm1176jz-s --with-fpu=vfp --with-float=hard --with-pkgversion='crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08' --with-bugurl=https://bugs.launchpad.net/gcc-linaro --enable-__cxa_atexit --enable-libmudflap --enable-libgomp --enable-libssp --with-gmp=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-mpfr=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-mpc=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-ppl=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-cloog=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-libelf=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-host-libstdcxx='-L/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static/lib -lpwl' --enable-threads=posix --disable-libstdcxx-pch --enable-linker-build-id --enable-plugin --enable-gold --with-local-prefix=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/install/arm-linux-gnueabihf/libc --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.7.2 20120731 (prerelease) (crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08)</code>

== Step Two: set-up your compiling environment ==

* Go back into the <code>raspberrypi</code> directory and create a subfolder named <code>rootfs</code>:
<code>cd
cd raspberrypi
mkdir rootfs</code>
* Now tell <code>rsync</code> to copy the entirety of the <code>/usr</code> and <code>/lib</code> directories of your RaspberryPi filesystem into the newly created folder on your computer:
<code>rsync -rl --delete-after --safe-links pi@$RASPI:/{lib,usr} $HOME/raspberrypi/rootfs</code>
where <code>$RASPI</code> is the IP address of the Raspberry. You can put this line of code in a text file and save it as a shell script for your convenience.
* Create a text file called <code>Toolchain-RaspberryPi.cmake</code> and insert the following into it:

SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 1)
# specify the cross compiler
SET(CMAKE_C_COMPILER $ENV{HOME}/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc)
SET(CMAKE_CXX_COMPILER $ENV{HOME}/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-g++)
# where is the target environment
SET(CMAKE_FIND_ROOT_PATH $ENV{HOME}/raspberrypi/rootfs)
# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

* Now you are able to compile your own projects using <code>cmake</code>, by passing the path of the Toolchain specification file to the program (supposing that the sources are located into a <code>src</code> directory which in turn is located into <code>${PROJECT_DIR}</code>):
<code>mkdir ${PROJECT_DIR}/build
cd ${PROJECT_DIR}/build
cmake -G"Eclipse CDT4 - Unix Makefiles" -D CMAKE_BUILD_TYPE=Debug -D CMAKE_TOOLCHAIN_FILE=$HOME/raspberrypi/Toolchain-RaspberryPi.cmake ../src</code>

== Step Three: Remote program execution through Eclipse ==

... to be continued ...

== References ==
* http://hertaville.com/2012/09/28/development-environment-raspberry-pi-cross-compiler/
* http://www.kitware.com/blog/home/post/426
* http://www.cmake.org/Wiki/CMake_Cross_Compiling

Cross-compiling for the RaspberryPi

2013-01-08T10:27:32Z

AndreaSalvi: /* Step One: installing the cross-compiler */

Cross-compiling for the RaspberryPi

2013-01-08T10:26:00Z

AndreaSalvi: /* Step One: installing the cross-compiler */

Cross-compiling for the RaspberryPi

2013-01-08T10:24:19Z

AndreaSalvi: /* Step One: installing the cross-compiler */

Cross-compiling for the RaspberryPi

2013-01-08T10:23:43Z

AndreaSalvi:

Talk:Robotic Battlefield Control

2013-01-08T10:22:04Z

AndreaSalvi: /* Related files and pages */

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

Cross-compiling for the RaspberryPi

2013-01-08T10:19:34Z

AndreaSalvi: Created page with "This page will guide you to setup a complete cross-compiling environment for the [www.raspberrypi.org RaspberryPi] board. This procedure is tailored for and tested on Ubuntu 1..."

This page will guide you to setup a complete cross-compiling environment for the [www.raspberrypi.org RaspberryPi] board. This procedure is tailored for and tested on Ubuntu 12.10, but it can be easily adapted for the use on other distributions.

== Prerequisites ==
* Install all the required software packages:
<code>sudo apt-get install git</code>

* '''If you are using a 64-bit version of Ubuntu''', also install the 32-bit compatibility libraries:
<code>sudo apt-get install ia32-libs</code>

* The guide will take for granted that you are using the official Raspbian OS image, downloadable from the RaspberryPi website.
* Moreover, you will need a working SSH connection between the Raspberry and your computer (not covered by this guide).

== Step One: installing the cross-compiler ==

* Select a directory in which you will install everything. For the purposes of this guide, I will consider a subdirectory of your home folder, <code>~/raspberrypi</code> . Create it and then access it:
<code>cd
mkdir raspberrypi
cd raspberrypi</code>

* Download the "official" cross-compiler of the Raspberry Pi project through <code>git</code>:
<code>sudo git clone git://github.com/raspberrypi/tools.git</code>
This will create, among other things, a <code>tools/arm-bcm2708</code> subfolder containing three different compiler toolchains:
** arm-bcm2708-linux-gnueabi
** arm-bcm2708hardfp-linux-gnueabi
** gcc-linaro-arm-linux-gnueabihf-raspbian

We are going to use the third of these toolchains, since it's the most optimized and supports the FPU that is available on the RaspberryPi board.

* Go back to your home directory, and open your <code>.bashrc</code> configuration file with any text editor, like <code>nano</code>, <code>gedit</code> or <code>leafpad</code>, and add this string at the bottom:
<code>PATH=$PATH:$HOME/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin</code>

* Now, either logout and login back again, or just close and reopen the terminal window, and type:
<code>arm-linux-gnueabihf-gcc -v</code>
If all goes well, you should see something like
<code>tudhalyas@gondor:~$ arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/home/tudhalyas/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../libexec/gcc/arm-linux-gnueabihf/4.7.2/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: /cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/src/gcc-linaro-4.7-2012.08/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=arm-linux-gnueabihf --prefix=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/install --with-sysroot=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/install/arm-linux-gnueabihf/libc --enable-languages=c,c++,fortran --disable-multilib --with-arch=armv6 --with-tune=arm1176jz-s --with-fpu=vfp --with-float=hard --with-pkgversion='crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08' --with-bugurl=https://bugs.launchpad.net/gcc-linaro --enable-__cxa_atexit --enable-libmudflap --enable-libgomp --enable-libssp --with-gmp=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-mpfr=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-mpc=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-ppl=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-cloog=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-libelf=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-host-libstdcxx='-L/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static/lib -lpwl' --enable-threads=posix --disable-libstdcxx-pch --enable-linker-build-id --enable-plugin --enable-gold --with-local-prefix=/cbuild/slaves/oort61/crosstool-ng/builds/arm-linux-gnueabihf-raspbian-linux/install/arm-linux-gnueabihf/libc --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.7.2 20120731 (prerelease) (crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08)</code>

== Step Two: set-up your compiling environment ==

... to be continued ...

== References ==
* http://hertaville.com/2012/09/28/development-environment-raspberry-pi-cross-compiler/
* http://www.kitware.com/blog/home/post/426
* http://www.cmake.org/Wiki/CMake_Cross_Compiling

Talk:Robotic Battlefield Control

2012-09-06T07:59:14Z

AndreaSalvi: /* ArchLinux */

== Related files ==
* [[File:RBC_state_diagrams.pdf‎]]

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

Talk:Robotic Battlefield Control

2012-09-06T07:58:52Z

AndreaSalvi:

== Related files ==
* [[File:RBC_state_diagrams.pdf‎]]

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

Talk:Robotic Battlefield Control

2012-09-05T16:51:46Z

AndreaSalvi:

== Related files ==
* [[File:RBC_state_diagrams.pdf‎]]

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

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

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

Talk:Robotic Battlefield Control

2012-09-05T09:35:36Z

AndreaSalvi: /* Useful and interesting links */

== Related files ==
* [[File:RBC_state_diagrams.pdf‎]]

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

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

Talk:Robotic Battlefield Control

2012-09-03T15:18:33Z

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

== Related files ==
* [[File:RBC_state_diagrams.pdf‎]]

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

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

Talk:Robotic Battlefield Control

2012-09-03T14:46:50Z

AndreaSalvi: /* Useful and interesting links */

== Related files ==
* [[File:RBC_state_diagrams.pdf‎]]

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

=== 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://geology.heroy.smu.edu/~dpa-www/robo/subsumption/]: notes about implementing a subsumption architecture in plain C

Talk:Robotic Battlefield Control

2012-09-03T13:31:44Z

AndreaSalvi: Link to the state diagrams file inserted.

File:RBC state diagrams.pdf

2012-09-03T13:23:58Z

AndreaSalvi: State diagrams for the Robotic Battlefield Control, part of the Robogames effort.

State diagrams for the Robotic Battlefield Control, part of the Robogames effort.

Talk:Robotic Battlefield Control

2012-07-22T13:33:29Z

AndreaSalvi: /* Useful and interesting links */

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

Talk:Robotic Battlefield Control

2012-07-21T16:36:49Z

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

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

Robotic Battlefield Control

2012-06-09T16:30:21Z

AndreaSalvi:

{{Project
| title=Robotic Battlefield Control
| short_descr=The goal of the project is to develop an interactive game between an autonomous robot and a remotely-controlled one, fighting for the control of a strategic point inside an arena-like playfield.
| coordinator=AndreaBonarini
| tutor=AndreaBonarini
| students=AndreaSalvi
| resarea=Robotics
| restopic=Robogames
| start=04/06/2012
| end=31/12/2012
| status=Active
| level = Ms
}}

'''Robotic Battlefield Control''' (or '''RBC''' for short) is a game developed as a part of the [[Robogames]] effort, loosely inspired by several videogames such as [http://www.leagueoflegends.com League of Legends] and [http://www.unrealtournament.com Unreal Tournament]'s ''Dominion mode''.

== Game Description ==

The participants are two identical robots, dubbed as ''RBC units'': one of these is autonomous, while the other one is remotely controlled by the player through an Android smartphone interface.

The game objective is to take and hold an area of the playfield, called ''strategic point''. This territory is "being hold" whenever one of the robots is in its immediate vicinities; for every second while one of the robots satisfy this condition, a counter is increased until a certain threshold (for example 60 seconds, or more) is reached. The first robot which is able to reach the threshold, wins. Note that if both robots are close to the strategic point, the area is being ''contended'', and neither of them will earn points towards the goal -- unless one of the robots has been disabled.

In fact, both robots are equipped with a (fictitious) rifle, and thus are able to shoot at each other. After a robot is hit several times, it shuts itself down for "autorepair" purposes for several seconds; once this operation is completed, it will reactivate itself at full health.

The arena where the game is set is filled with walls that act as visual obstacles, which can provide cover for guerrilla actions such as ambushes.

== Additional Information ==

More information will be available both on this page, and on its relative [[{{TALKPAGENAME}}|Discussion]] page.

User:AndreaSalvi

2012-06-09T16:26:26Z

AndreaSalvi:

{{SMWUser
|firstname=Andrea
|lastname=Salvi
|email=andrea2.salvi@mail.polimi.it
|advisor=AndreaBonarini
|projectpage=Robotic Battlefield Control
|photo=AndreaSalvi.jpg
|status=active
}}

Andrea Salvi

Matricola: 721287

Nato ad Alzano Lombardo il 03-05-1984

Istruzione e formazione

- settembre 2007: Laurea in Ingegneria Informatica (1° livello) presso il Politecnico di Milano

- luglio 2003: Maturità Scientifica presso il Liceo Scientifico Mascheroni di Bergamo

Robotic Battlefield Control

2012-06-09T16:22:14Z

AndreaSalvi: Created page with "{{Project | title=Robotic Battlefield Control | short_descr=The goal of the project is to develop an interactive game between an autonomous robot and a remotely-controlled o..."

File:AndreaSalvi.jpg

2012-05-27T14:44:09Z

AndreaSalvi: uploaded a new version of "File:AndreaSalvi.jpg"

File:AndreaSalvi.jpg

2009-03-22T12:48:43Z

AndreaSalvi:

User:AndreaSalvi

2009-03-22T12:47:37Z

AndreaSalvi: First version of the page.

{{SMWUser
|firstname=Andrea
|lastname=Salvi
|email=tudhalyas(at)gmail(dot)com
|advisor=NicolaGatti
|projectpage=Real-Time Strategy Games
|photo=AndreaSalvi.jpg
}}

Andrea Salvi

Matricola: 721287

Nato ad Alzano Lombardo il 03-05-1984

Istruzione e formazione

- settembre 2007: Laurea in Ingegneria Informatica (1° livello) presso il Politecnico di Milano

- luglio 2003: Maturità Scientifica presso il Liceo Scientifico Mascheroni di Bergamo