Difference between revisions of "Footbot/Real robot information"
From IridiaWiki
Jump to navigationJump to searchManubrambi (talk | contribs) |
|||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | This page does not exist anymore. Please go to: |
||
| − | = EPFL LSRO Wikipages = |
||
| + | http://iridia-dev.ulb.ac.be/projects/argos/trac/wiki/WikiStart#RealRobotInformation |
||
| − | For updated info go to the EPFL wiki. |
||
| − | http://wiki.epfl.ch/mobots-robots |
||
| − | |||
| − | = Downloading ARGoS2 = |
||
| − | |||
| − | To download ARGoS2, you need git. First, create the file ~/.netrc with this content: |
||
| − | |||
| − | machine iridia-dev.ulb.ac.be |
||
| − | login YOUR_USERNAME |
||
| − | password YOUR_PASSWORD |
||
| − | |||
| − | and secure it: |
||
| − | |||
| − | $ chmod 600 ~/.netrc |
||
| − | |||
| − | Subsequently, configure git (once and for all) to accept Iridia dev's autosigned certificate: |
||
| − | |||
| − | $ git config --global http.sslVerify false |
||
| − | |||
| − | Finally, download the code: |
||
| − | |||
| − | $ git clone https://iridia-dev.ulb.ac.be/projects/argos2.git argos2 |
||
| − | |||
| − | = Downloading and installing Aseba = |
||
| − | |||
| − | Download Dashel: |
||
| − | svn co http://svn.gna.org/svn/dashel/trunk dashel |
||
| − | |||
| − | Install Dashel: |
||
| − | cmake . |
||
| − | make |
||
| − | sudo make install |
||
| − | |||
| − | Download Aseba (revision 403 as revisions 404 and 405 have compilation bugs) |
||
| − | svn co -r 403 http://svn.gna.org/svn/aseba/trunk aseba |
||
| − | |||
| − | Check that you have QT4 install (qt4-qmake and libqt4-dev). If not, install them, then install aseba: |
||
| − | cmake . |
||
| − | make |
||
| − | sudo make install |
||
| − | |||
| − | Check if Aseba studio has been compiled |
||
| − | cd studio |
||
| − | ./asebastudio |
||
| − | |||
| − | if asebastudio is missing it means that you don't have the necessary qt4 lib installed. |
||
| − | |||
| − | = Connecting to a footbot = |
||
| − | |||
| − | Wifi uses wpasupplicant to connect to a WPA-PSK access point. You can use USB or Bluetooth to connect to the robot otherwise. Set the selector on the robot top to an even value for USB, and uneven to Bluetooth. |
||
| − | |||
| − | == USB == |
||
| − | |||
| − | Put the following lines into ~/.ssh/config: |
||
| − | |||
| − | host footbot_usb |
||
| − | hostname 192.168.0.202 |
||
| − | user root |
||
| − | |||
| − | Then, configure the interface and connect: |
||
| − | |||
| − | sudo /sbin/ifconfig usb0 192.168.0.200 netmask 255.255.255.0 |
||
| − | ssh footbot_usb |
||
| − | |||
| − | In asebastudio, to connect use |
||
| − | |||
| − | tcp:host=192.168.0.202;port=33333 |
||
| − | |||
| − | == Bluetooth == |
||
| − | |||
| − | === udev setup === |
||
| − | |||
| − | First, you have to setup the bluetooth connection via udev. We'll use 10:00:E8:6C:F0:4D and a handbot1 as an example here, replace accordingly. You have to be root for that. |
||
| − | |||
| − | hcitool scan |
||
| − | |||
| − | Take note of the MAC address displayed. |
||
| − | |||
| − | cd /etc/bluetooth/ |
||
| − | mkdir -p passkeys |
||
| − | echo -n '0000' > passkeys/10:00:E8:6C:F0:4D |
||
| − | |||
| − | Edit the file /etc/rfcomm.conf and add the following line: |
||
| − | |||
| − | rfcomm1 { bind yes; device 10:00:E8:6C:F0:4D; } |
||
| − | |||
| − | Edit the file /etc/udev/rules.d/90-local.rules and add the following line: |
||
| − | |||
| − | ACTION=="add", SUBSYSTEM=="tty", KERNEL=="rfcomm[0-9]*", WAIT_FOR_SYSFS="address", ATTR{address}=="10:00:E8:6C:F0:4D", SYMLINK+="handbot1", MODE="0666" |
||
| − | |||
| − | Create the serial connection: |
||
| − | |||
| − | rfcomm connect /dev/rfcomm1 |
||
| − | |||
| − | You should then see the device /dev/handbot1 linked to /dev/rfcomm1. |
||
| − | |||
| − | === Connect with aseba === |
||
| − | |||
| − | Connect with aseba using the following connection string: |
||
| − | |||
| − | ser:device=/dev/handbot1 |
||
| − | |||
| − | === Connect to the IMX === |
||
| − | |||
| − | ==== Where to put the mini key on the footbots? ==== |
||
| − | |||
| − | The connector for a connection to the IMX is "UART1" next to the IMX. The key as to be outward facing (usually it's marked white on the side for pin 1, look for the 1 on the PCB). |
||
| − | |||
| − | ==== Connect to shell ==== |
||
| − | |||
| − | Setup the device as described above so that the serial device /dev/footbotX exists. Then, use minicom or similar to connect to the device. |
||
| − | |||
| − | minicom -s |
||
| − | |||
| − | Change the serial port to the device of the robot. Then select exit and press enter 2-3 times. You should see a shell. |
||
| − | |||
| − | == Wifi == |
||
| − | |||
| − | Works "normally" pretty reliable when used with '''static''' IPs. Follow the instructions on http://wiki.epfl.ch/mobots-robots/Wifi h. |
||
| − | |||
| − | = Booting = |
||
| − | |||
| − | To boot the robot, insert the battery. The boot is finished when the beacon lights up in RED->GREEN->BLUE. The flashing LED on the IMX signals a successful boot of the linux system. '''Beware of the sudden movement of the robot as it's booting. NEVER put it on a table when testing.''' |
||
| − | |||
| − | == Buttons & LEDs == |
||
| − | |||
| − | There are two buttons next to the selector. Press them to reset the translator and the dsPics. Usually, when there's strange stuff happening on low-level (i.e. when you have problems with aseba), press the "reset dsPics". After pressing this button, reload the backend! |
||
| − | |||
| − | The red led on the IMX next to the battery holder indicates the status of the IMX. It should be flashing. If it stops flashing, there was a kernel panic and you have to reset the IMX. |
||
| − | |||
| − | There's a reset button between the charge connector and the IMX. Press it to reset the IMX and therefore the robot, including the dsPics. This button should '''only''' be used in the rare case that the IMX/Linux hangs (red led stopped flashing). |
||
| − | |||
| − | The four green LEDs below the selector indicate aseba activity. If they stand still it means that there are no events sent, and therefore that the sensors are dead. Reset the dsPics if necessary, and reload the backend (/etc/init.d/ARGoS.sh start). |
||
| − | |||
| − | = Connect with aseba = |
||
| − | |||
| − | Connect with aseba with this custom destination: |
||
| − | |||
| − | tcp:host=192.168.0.202;port=33333 |
||
| − | |||
| − | == Does not work? == |
||
| − | |||
| − | If Aseba connection doesn't work, try again without killing asebamedulla; otherwise, close Asebastudio. Restart |
||
| − | asebamedulla, the pics and reload the backend |
||
| − | |||
| − | /etc/init.d/asebamedulla.sh restart |
||
| − | /etc/init.d/dspics-power.sh restart |
||
| − | /etc/init.d/ARGoS.sh restart |
||
| − | |||
| − | If this does not work, reset the translator and the pic per button. Rerun asebamedulla and try connecting. |
||
| − | |||
| − | If this does not work, do the same as above with setting the selector to another even value (NOT an odd one!). Try |
||
| − | connecting again. |
||
| − | |||
| − | = Battery = |
||
| − | |||
| − | * full battery = 4.2V |
||
| − | * empty battery < 3.6V |
||
| − | |||
| − | The charger we have at Iridia damages the batteries. |
||
| − | We were given 12 batteries; to limit the number of damaged batteries, 10 batteries, when empty, won't be recharged. |
||
| − | Only two batteries will be recharged. |
||
| − | |||
| − | = Sensors = |
||
| − | |||
| − | == Camera == |
||
| − | |||
| − | Cameras don't work at the same time; you can use them one by one. |
||
| − | |||
| − | If you want to stream images out of the footbot camera, in /home/root/ARGoS/bin you will find |
||
| − | a program named mobotsvision. It is a streaming server. |
||
| − | |||
| − | To use it, the syntax is: |
||
| − | |||
| − | $ cd /home/root/ARGoS/bin |
||
| − | $ ./mobotsvision <omnidirectional|ceiling> <gain> <exposure> |
||
| − | |||
| − | The first argument lets you select the camera to stream images from; the gain is the amount |
||
| − | of signal amplification you want (0-127). A low value makes the images darker, a high value makes them |
||
| − | brighter but also much noisier. The exposure is the total amount of light allowed to fall into the CCD |
||
| − | sensor. Its range is 0-255. A low value makes images very dark, a high value makes them very bright. The |
||
| − | exposure is linked to the time needed to take an image; a low value entails high frame rate, a high value |
||
| − | entails low frame rate. |
||
| − | |||
| − | When running the server, if you get an error such as: |
||
| − | |||
| − | [FATAL] Cannot open /dev/video0: Input/output error |
||
| − | |||
| − | then try unbinding the driver and then binding it back. You do it this way: |
||
| − | |||
| − | $ echo 0-0 > /sys/bus/soc-camera/drivers/camera/unbind |
||
| − | $ echo 0-0 > /sys/bus/soc-camera/drivers/camera/bind |
||
| − | |||
| − | |||
| − | When programming a low level tool for the robot, to select the camera to use, echo to file |
||
| − | /sys/class/gpio/gpio28/value a value of 0 for the omnidirectional camera and 1 for the front one. |
||
| − | The camera module is mt9t031.ko. |
||
| − | |||
| − | For problems, the EPFL guy to ask is Valentin Longchamps <valentin.longchamps@epfl.ch>. |
||
| − | |||
| − | = Actuators = |
||
| − | |||
| − | == Turret Rotation == |
||
| − | |||
| − | At boot, the robot sets the 0 position of the turret. To avoid damaging the robot or having funny values, always put the gripper back in the 0 position and then switch the robot on. It can be done also when the robot is on already: set the variable 'rev.pid.enable' to 0 and rotate the turret back to its position. Then select 'Tools->Reboot->Griper-led' and the new 0 position will be set. |
||
| − | |||
| − | = Framework = |
||
| − | |||
| − | == Compiling ARGoS for the real robot == |
||
| − | |||
| − | Download and install the toolchain from http://wiki.epfl.ch/mobots-robots/toolchain . It is recommended to install it system-wide because it hasn't been tested otherwise. |
||
| − | |||
| − | === By script === |
||
| − | |||
| − | Each package has a script that takes care of building it. You need the toolchain of course. The script is called build_real_robot.sh and should be invoked as follows: |
||
| − | |||
| − | ./build_real_robot.sh footbot |
||
| − | |||
| − | There is also a top-level build script that builds the common, real robot and user package. |
||
| − | |||
| − | ./build_real_robot_framework.sh footbot |
||
| − | |||
| − | === By hand === |
||
| − | |||
| − | Configure your environment for cross-compilation: |
||
| − | |||
| − | source /usr/local/angstrom/arm/environment-setup |
||
| − | |||
| − | Then, compile the common package: |
||
| − | |||
| − | cd $ARGOSINSTALLDIR |
||
| − | cd common |
||
| − | mkdir -p build/footbot |
||
| − | cd build/footbot |
||
| − | cmake -DARGOS_COMPILE_REAL_FOOTBOT=1 ../.. |
||
| − | make |
||
| − | |||
| − | If everything goes OK, compile the real robot swarmanoid common package: |
||
| − | |||
| − | cd $ARGOSINSTALLDIR |
||
| − | cd real_robot |
||
| − | mkdir -p build/swarmanoid/common |
||
| − | cd build/swarmanoid/common |
||
| − | cmake ../../../swarmanoid/common |
||
| − | make |
||
| − | |||
| − | If everything goes OK, compile the real robot swarmanoid footbot package: |
||
| − | |||
| − | cd $ARGOSINSTALLDIR |
||
| − | cd real_robot |
||
| − | mkdir -p build/swarmanoid/footbot |
||
| − | cd build/swarmanoid/footbot |
||
| − | cmake ../../../swarmanoid/footbot |
||
| − | make |
||
| − | |||
| − | If everything goes OK, compile the user package: |
||
| − | |||
| − | cd $ARGOSINSTALLDIR |
||
| − | cd user/my_user |
||
| − | mkdir -p build/footbot |
||
| − | cd build/footbot |
||
| − | cmake -DARGOS_COMPILE_REAL_FOOTBOT=1 ../.. |
||
| − | make |
||
| − | |||
| − | == Installing the libraries in the real robot == |
||
| − | |||
| − | If you log into the robot, you'll notice a directory ARGoS. It contains the aseba backend (aseba_backend.aesl), some useful tools in bin/ and |
||
| − | a directory lib/ in which the ARGoS libraries are stored. Whenever you fix the common or real robot packages, you have to update these libraries. |
||
| − | |||
| − | === By script === |
||
| − | |||
| − | There's a script in the $ARGOSINSTALLDIR that calls make install for all packages and then copies the libs, the backend and the controller to the specified robot via ssh. Currently it works only for the footbot. It has to be invoked as follows: |
||
| − | |||
| − | ./update_real_footbot.sh <controllername> <hostname> |
||
| − | |||
| − | The controller is taken from $ARGOSINSTALLDIR/user/my_user/controllers/<controllername>. |
||
| − | |||
| − | === By hand === |
||
| − | |||
| − | Create a directory to install ARGoS locally: |
||
| − | |||
| − | cd $ARGOSINSTALLDIR |
||
| − | mkdir install |
||
| − | |||
| − | Install the common package libraries: |
||
| − | |||
| − | cd common/build/footbot |
||
| − | DESTDIR=../../../install make install |
||
| − | |||
| − | Same thing for the real robot swarmanoid common package: |
||
| − | |||
| − | cd $ARGOSINSTALLDIR |
||
| − | cd real_robot/build/swarmanoid/common |
||
| − | DESTDIR=../../../../install make install |
||
| − | |||
| − | Same thing for the real robot swarmanoid footbot package: |
||
| − | |||
| − | cd $ARGOSINSTALLDIR |
||
| − | cd real_robot/build/swarmanoid/footbot |
||
| − | DESTDIR=../../../../install make install |
||
| − | |||
| − | Now go into the install directory: |
||
| − | |||
| − | cd $ARGOSINSTALLDIR |
||
| − | cd install |
||
| − | |||
| − | And get into the directory where the libraries have been copied: |
||
| − | |||
| − | cd usr/local/lib/argos2 |
||
| − | ls |
||
| − | |||
| − | Copy all the libraries onto the robot: |
||
| − | |||
| − | scp * root@footbot_usb:~/ARGoS/lib/ |
||
| − | |||
| − | == Using your controller on the real robot == |
||
| − | |||
| − | So you managed to compile the controller on your pc and maybe also to update the libraries. Now what? |
||
| − | |||
| − | When you have compiled your controller you will see that in "build/controller/name_of_your_controller/" you will find and executable file. This file has to be uploaded to the real robot. |
||
| − | |||
| − | Once this is done, connect with aseba to the robot (good luck) and then you execute aseba_backend.aesl (you can find this file on the robot, under ~/ARGoS). |
||
| − | |||
| − | Now you can run your controller: |
||
| − | |||
| − | [on the robot] ./your_controller -c FILECONFIG.xml -i ID_CONTROLLOR |
||
| − | |||
| − | where FILECONFIG.xml is the same xml you used in your simulated experiments and ID_CONTROLLER is the id of your controller (really?) meaning the id that is in the xml. For example, with the "footbot_obstacle_avoidance" controller, you would execute: |
||
| − | |||
| − | ./footbot_obstacle_avoidance -c obstacle_avoidance.xml -i sfc |
||
| − | |||
| − | === Crashes? === |
||
| − | |||
| − | After your controller crashes you have to reset the whole robot, because aseba/dashel gets into a bad state. |
||
| − | |||
| − | == Using the joypad to control a footbot == |
||
| − | |||
| − | If you want to test the robots with the joypad you need a program that converts the input from your joypad to events into aseba. This program is called "asebarc" and you can ask it to Manuele, Carlo or Eliseo. Once you have compiled this, connect to the robot with aseba and run "marxbot-swarmanoid-rc.aesl" (as before, ask this file to somebody). On your pc, run "asebarc" with this command: |
||
| − | ./asebarc "tcp:host=192.168.0.202;port=33333" |
||
| − | |||
| − | You should now be able to control the footbot with the joypad. |
||
| − | |||
| − | One last thing that you have to know is that the buttons on the back of the joypad (R2 and L2, i think) are used to switch the mode of the turret between passive and rigid. The button that turns the light blue set the turret passive, while the one that turns the light green turns the turret rigid. |
||
Latest revision as of 10:57, 20 April 2010
This page does not exist anymore. Please go to:
http://iridia-dev.ulb.ac.be/projects/argos/trac/wiki/WikiStart#RealRobotInformation
