RoboJackets Wiki - User contributions [en]

RoboCup Base Station

2010-08-31T21:03:48Z

BenJ: Created page with 'The base station works in two modes: host (standalone) and device. In standalone mode, the base station can be used without a computer to drive robots for mechanical testing and...'

The base station works in two modes: host (standalone) and device. In standalone mode, the base station can be used without a computer to drive robots for mechanical testing and demos.

There are two USB connectors: type A (host) and type B (device). Only connect one of these at a time. The data lines are connected between them and nothing will work if both are connected.

The base station can be powered by external power (required for standalone mode) or from the USB B connector. External power is not required in device mode unless you have a very broken USB hub.

The base station will operate in device mode if the USB B connector has power on reset.

== Antenna ==
There is an SMA antenna connector. Always check the antenna connector to be sure you are using an SMA (not RP-SMA) connector. An RP-SMA connector is mechanically compatible with the base station but will not make an electrical connection.
The antenna must work at 902MHz.

== Standalone Mode ==
Connections:
* Antenna
* Power: 6-12V DC, center positive, 2.1mm pin
* Joystick to USB A
Do not connect USB B.

Standalone mode will work with either the Logitech RumblePad 2 or Logitech Dual Action Gamepad. These are the two controllers currently supported by soccer as well.

== Standalone Controls ==
Driving is the same as in soccer:
* '''Left X''': Rotate.
* '''Right analog stick''': Translate.
* '''Left Y + Button 5''': Dribbler. Release button 5 to latch dribbler speed.
* '''Button 8''': Kick, full power.
* '''Button 6''': Chip, full power.

Robot selection is done with the controller:
* '''Button 10''': Select robot 0
* '''Buttons 1-4''': Select robots 1-4
Other robot IDs cannot be driven in standalone mode for lack of buttons.

== Device Mode ==
This is normally used for competition.

Connections:
* Antenna
* Computer to USB B
Do not connect USB A.

== Programming ==
The AT90USB1287 has a built-in bootloader ROM which will enumerate as a USB device. <tt>dfu-programmer</tt> can be used to program the device.

Inside, there are two buttons. The one nearest to the LEDs is PROGRAM and the other is RESET. To program the base station, you must hold PROGRAM while releasing RESET. You can do this by rolling your finger over the two buttons.

Programming steps:
* Connect the base station in device mode.
* Reset the device while holding the PROGRAM button.
* <tt>make prog</tt> in the <tt>electrical/base_station/current/fw</tt> directory.

There is a USB control command to start the bootloader. This is finicky and depends on the firmware already working, so I don't bother with it.

Note that <tt>dfu-programmer</tt> and <tt>radio</tt> must have privileges for the base station. <tt>software/util/robocup.rules</tt> should be copied to <tt>/etc/udev/rules.d</tt> before plugging in the base station to give the proper privileges for both the bootloader and normal operation.

RoboCup Soccer

2010-08-03T02:19:49Z

BenJ:

The ''soccer'' program encompasses everything that happens between ''vision'' and ''radio''.

==Invocation==
For command-line help:
<pre>
./soccer --help
</pre>

All command line options except <tt>-sim</tt> and <tt>-nolog</tt> can also be changed in the GUI.

If a <tt>logs</tt> directory is present in the current directory when <tt>soccer</tt> is started, it will write a log file named with the date and time the program was started. This can be disabled with the <tt>-nolog</tt> option. You typically don't need to log data during simulation.

All options have defaults. If <tt>soccer</tt> is started with no arguments, it will start in a configuration suitable for competition.

If no configuration file is given, <tt>soccer</tt> will read <tt>soccer-sim.cfg</tt> or <tt>soccer-real.cfg</tt> from the current directory, depending on the <tt>-sim</tt> option.

The typical command line for off-line development and testing is <tt>./soccer -sim</tt>.

==Operation==

===Team and Field Configuration===
There are two parameters that must be set before each half of a match: team and defending goal.
The team (yellow or blue) can be set with the <tt>Field -> Team</tt> menu.
The goal we defend, identified by its position in vision space, can be set with the <tt>Field -> Defend Goal</tt> menu.

The current team is shown next to the status indicator.

===Field View===
The orientation of the field view can be changed in the View menu to correspond with the physical setup of the computer on a real field.

Team space and vision space coordinate frames can be shown on the field with <tt>View -> Coordinate Frames</tt>

The field view allows you to control the simulator and manual driving:
* Left-clicking on a robot drags the robot
* Left-clicking away from a robot places and drags the ball
* Right-clicking on a robot selects it for manual control (if a joystick is present)

===Tree===
The tree is automatically generated from Packet::LogFrame using Google Protocol Buffers' reflection mechanism. By default, non-repeated messages are expanded and repeated messages are not. There are options in the context menu to expand and collapse items.

===Logging===
There is a circular buffer of recent log data even if no log file is being created. You can use the log controls to move through this data and see the recent history of the game. The amount of log data available for instant replay is shown in the status bar.

The field view and tree can show either live or historical data. All controls showing historical data have a red outline. Some controls, such as the Plays tab and the status label, only show live data.

*Use the playback rate slider to move through recorded data: center is stopped, left is backwards, and right is forwards. The display stops when you start moving the playback slider or when you click on the pause button.
*Use the <tt>Next Frame</tt> and <tt>Previous Frame</tt> buttons to step through data.
*Use the <tt>Live</tt> button to continuously see current data.

===Status Indicator===
There is a status indicator in the upper right corner of the main window. Its text and color indicates the readiness of the whole system for competition. If everything is ready for a real match, the indicator will show COMPETITION. Otherwise, the indicator will be red for serious system problems or yellow for configuration problems. It will never be green except when the entire system is ready to run.

===Manual Driving===
You must have a compatible gamepad connected for manual driving. We recommend the Logitech Cordless Rumblepad 2 or its wired equivalent.

Select a robot either by right-clicking on it in the field view (must be on this soccer's team) or selecting its shell ID in the <tt>Manual</tt> combobox.

Controls:
* Button 1 starts autonomous operation
* Button 3 stop autonomous operation (manual driving still works)
* The D-pad allows precise direction control at full speed
* The right analog stick's X-axis is rotation
* The left analog stick controls translation
* Holding button 7 (lower left shoulder) lets you control the roller with the right analog stick's Y-axis
* Pressing button 5 (upper left shoulder) saves or restores the current roller speed
* Pressing button 8 (lower right shoulder) fires the kicker at full power when the ball is detected

==Communications==
Simulation and real-robot operation are essentially the same. They differ only by the type of network communication used.

* Real vision and referee data uses UDP multicast.
* Simulated vision data is sent as two separate copies to different UDP unicast ports on <tt>localhost</tt>. This avoids the need to configure local multicast or broadcast.

See <tt>software/common/Network.hpp</tt> for details.

There are provisions for two radio channels to allow two teams to play with the same hardware and software components. The radio channel is shown above the team indicator. There is currently no provision for changing channels on the robots, so this is only useful in simulation. This is an electronics (firmware) upgrade item.

==Major Components==
; [[World Modeling]] : Develops models of the world based on available information from multiple systems
; [[Robocup StateID | StateID]] : Assigns semantic labels to game states to aid in behavior selection
; Gameplay : Plays and Behaviors. Play selection and behavior definitions.
; [[Motion]] : Low level robot planning and motion control

; [[Robocup Play Development HOWTO]] : How to add plays to the system so they can be compiled and used

RoboCup Simulator

2010-08-03T01:41:32Z

BenJ:

The simulator, <tt>soccsim</tt>, is used heavily for off-line development and testing. It provides the same interfaces as <tt>ssl-vision</tt> and <tt>radio</tt>, allowing <tt>soccer</tt> to run in (nearly) the same way for simulation and real operation.

==Invocation==
<pre>
./soccsim [-c <config file>] [--ui] [--sv]
</pre>

If no configuration file is given, it will use <tt>simulator.cfg</tt> in the current directory.

* <tt>--ui</tt> displays a GUI that is really only useful for debugging the geometry given to the physics engine.
* <tt>--sv</tt> causes the simulator to send data to the <tt>ssl-vision</tt> multicast address. Do not use this on a competition network!

==Limitations==
* No noise.
* Only outputs data for one camera. Ball-occlusion simulation is still done as if there were two cameras.
* No carpet effects such as loss of traction and variable height.
* Only partial simulation of robot status in RadioRx packets.

RoboCup Simulator Execution

2010-08-03T00:50:56Z

BenJ:

The easiest way to get started using the software is to make use of the simulator, which will be most useful for developing much of the actual system. The first scenario will start a simulator with a single robot, and the second scenario will start two teams with referee control.

All of the commands on this page assume you are in the software/run directory.

== Single-team Simulator Use ==
In this case, we will only drive one team. The other team's robots will remain stationary.

=== Starting the Simulator ===
<pre>
./soccsim [-c <config file>]
</pre>

If no configuration file is given, it will use default.cfg in the current directory. Currently, default.cfg creates two full teams.

You can kill the simulator with Ctrl-C.

=== Starting one team ===
In another terminal, in the software/run directory:
<pre>
./soccer -sim
</pre>

The status indicator in the upper right corner should be yellow and show SIMULATION.

You can now issue internal referee commands. Either use the shortcut buttons at the top of the window for the most common commands (they have tooltips) or go to the Referee tab for a complete set of commands.

== Starting two teams ==
Start another soccer program exactly like the first one. Don't use the referee buttons yet - the two soccers won't stay in sync.
Set the second soccer to run the blue team (Field -> Team Color -> Blue) and defend the opposite goal (Field -> Defend Goal -> Vision +X).

You must use the SSL referee box to control two soccers at once.

If you are not connected to a network, you must add a multicast route:
<pre>
../util/mcast_route lo
</pre>

You can reverse this later with:
<pre>
../util/mcast_route
</pre>
but the route will typically be removed by your network manager when you get a real network connection.

Now start the SSL referee box:
<pre>
./sslrefbox
</pre>

The referee buttons in both soccers should now be grayed out and the Use external referee checkbox should be checked. If you have previously changed this checkbox manually, you will need to check it.

You can now use the SSL referee box to issue commands to both soccers at once.

RoboCup Simulator Execution

2010-01-31T22:23:24Z

BenJ:

The easiest way to get started using the software is to make use of the simulator, which will be most useful for developing much of the actual system. For these instructions, you will need to be in a terminal in your robocup folder (/robocup/software/trunk). The first scenario will start a simulator with a single robot, and the second scenario will start two teams with referee control.

== Before starting the simulator ==
To avoid flooding the network with data from your simulator, we have a script to reroute some networking processes. You will need to follow these instructions once before running the simulator, but the setting will remain correct until you reboot.

<pre>
sudo ./doc/mcast_route lo
</pre>

== Single-team Simulator Use ==
In this case, we will only drive one team, the other team's robots will just remain stationary

=== Starting the Simulator ===
We will start the simulator to run in a terminal. You can run the soccsim executable without parameters to get a small explanation of the correct arguments, if necessary. Note that you can choose from the config files in the SoccSim/config/ folder to try different scenarios.

<pre>
cd ./SoccSim/bin
./soccsim -c ../config/two_teams.xml
</pre>

Now the simulator should report that it is running. To stop the simulator, kill the process by typing Ctrl-C in the terminal where you started it.

=== Starting the soccer interface ===
Start a new terminal to run soccer from and use the following commands. This will start the soccer engine using the simulation configuration file (soccer/config/sim.xml) and using the yellow team (use -b for blue team).

<pre>
cd [robocup root]/soccer/bin
./soccer -y -c ../config/sim.xml
</pre>

You should now see the GUI for the soccer program. To to a simple check to ensure that everything is working, you want to enable a play to run. Go to the plays tab and select "testBasicAttack" from the list, then click the green check button (Force Start) in the upper left of the GUI. You should see one robot go to the goal (because goalie is enabled by default), and another robot drive at the ball and start kicking.

== Using the Soccer interface ==
There's a lot of data available in the GUI to make debugging the robots easier. The best place to look if you want to see what the robots are doing is in the tree view tab, where all of the data logged or passed through the system is shown in realtime.

RoboCup Simulator Execution

2010-01-31T22:23:00Z

BenJ:

The easiest way to get started using the software is to make use of the simulator, which will be most useful for developing much of the actual system. For these instructions, you will need to be in a terminal in your robocup folder (/robocup/software/trunk). The first scenario will start a simulator with a single robot, and the second scenario will start two teams with referee control.

== Before starting the simulator ==
To avoid flooding the network with data from your simulator, we have a script to reroute some networking processes. You will need to follow these instructions once before running the simulator, but the setting will remain correct until you reboot.

<pre>
sudo ./doc/mcast_route lo
</pre>

== Single-team Simulator Use ==
In this case, we will only drive one team, the other team's robots will just remain stationary

=== Starting the Simulator ===
We will start the simulator to run in a terminal. You can run the soccsim executable without parameters to get a small explanation of the correct arguments, if necessary. Note that you can choose from the config files in the SoccSim/config/ folder to try different scenarios.

<pre>
cd ./SoccSim/bin
./soccsim -c ../config/two_teams.xml
</pre>

Now the simulator should report that it is running. To stop the simulator, kill the process by typing Ctrl-C in the terminal where you started it.

=== Starting the soccer interface ===
Start a new terminal to run soccer from and use the following commands. This will start the soccer engine using the simulation configuration file (soccer/config/sim.xml) and using the yellow team (use -b for blue team).

<pre>
cd [robocup root]/soccer/bin
./soccer -y -c ../config/sim.xml -p ../playbooks/Default.pbk
</pre>

You should now see the GUI for the soccer program. To to a simple check to ensure that everything is working, you want to enable a play to run. Go to the plays tab and select "testBasicAttack" from the list, then click the green check button (Force Start) in the upper left of the GUI. You should see one robot go to the goal (because goalie is enabled by default), and another robot drive at the ball and start kicking.

== Using the Soccer interface ==
There's a lot of data available in the GUI to make debugging the robots easier. The best place to look if you want to see what the robots are doing is in the tree view tab, where all of the data logged or passed through the system is shown in realtime.

RoboCup Simulator Execution

2009-10-11T18:56:41Z

BenJ: /* Running Under Simulation */

== Running Under Simulation ==
* Reroute the multicast packets - this is to keep your simulator from flooding any network you are on with vision packets.
** Starting from the software/trunk folder
** cd doc/
** ./mcast_route lo [requires root password]
* Start the simulator itself with a configuration to describe how many robots it starts with. There are multiple configurations available in the SoccSim/config folder, but two_teams will provide the default for most soccer applications.
**cd SoccSim/bin
**./soccsim -c ../config/two_teams.xml
* At this point, there is a small wireframe display of the field with robots, but it isn't particularly interactive. To actually do robot control and soccer playing, you will need to create instances of soccer for each team.
**Starting from the previous step
**cd ../../soccer/bin
**./soccer -b -c ../config/sim.xml
*** This command starts soccer with the blue team (-b) flag, the robot configuration for the simulator. To specify the other team, use -y instead of -b. The sim config should be used whenever the simulator is used.

RoboCup Radio 2009

2008-09-10T17:49:45Z

BenJ:

=Bandwidth=
* 90Hz cycles => 11ms period.
* 250kbaud maximum. The radio can do 500kbaud with some modulation types, but we can not assume that this will be the final choice.
** Raw: 347 bytes per period, less 23 bytes for VCO calibration time. 324 bytes usable.
* 12 bytes overhead per packet
** 4 bytes preamble (recommended by datasheet, 2 bytes minimum)
** 4 bytes sync (recommended by datasheet, 2 bytes minimum)
** 1 or 2 bytes padding for error correction (payload must be an odd number of bytes before padding)
** 2 bytes CRC
** Separate overhead for forward and reverse packets
* Maximum packet size is 255 bytes, excluding FEC padding and CRC.

=Configuration=
Need to consider a reliable communication protocol for performing robot configuration

* Radio configuration
* PID loops
* etc...

This is not done often, but a host-side application for this would be nice.

=Channels=
* A small number of channel configurations (8-16?) should be stored on the robot for scanning. Would prefer EEPROM on MCU for this. Should not require JTAG flash to change these.
** Channel config includes bit rate, modulation, power, etc. Everything can be configured per channel.
** These *will* change during competition. Expect frequent changes during setup as other teams go online and crowd us out.
** Too many possible channels to scan in an acceptable amount of time.
* Each robot will scan for the host among the channels it knows on power-on and when it has received no radio data in some period of time (5s?).
** Expect to wait at least 3 radio cycles (33ms) on each channel. If we miss three forward packets in a row, either the host is on another channel or the channel is unusable.
* Not sure how to select a channel for standalone mode.
** Use last channel assigned by host, stored on the base
** Select with joystick
** Clear Channel Assessment (find lowest noise among configured channels)

=Scanning=
Looking for robots that are turned on.
* This should be done per request of the host. Most likely during a ''stop/halt'' in gameplay because we do not reverse channel data then.
* Should be able to change a robot on the field without touching the computer.

=Protocols=
==Forward==

==Reverse==
Under normal operating conditions the reverse channel has several different modes of operation.

# Gameplay Mode
#* Slow Update: All robots are reporting back every ''nth robot'' fast loop interval.
#* Fast Update: Only one robot is reporting back, but is reporting every fast loop.
# Fast Engineering data
# Slow Engineering data

===Information Types===
There are three types of information that need to come back over the reverse channel. They are in order of priority.

====Gameplay====
Gameplay information needs to be updated frequently and is critical to good gameplay.
* Ball Presence
* Capacitor Voltage

====Fast Engineering====
These are things that we want to know periodically, but are not updated very quickly or are not critical to gameplay.
* Battery Health/Voltage
* RSSI

====Slow Engineeting====
Items that do not change at all or change very slowly during a match.
* Board serial number

RoboCup Radio 2009

2008-09-10T17:38:10Z

BenJ: /* Channels */

=Configuration=
Need to consider a reliable communication protocol for performing robot configuration

** Radio configuration
** PID loops
** etc...

This is not done often, but a host-side application for this would be nice.

=Channels=
* A small number of channel configurations (8-16?) should be stored on the robot for scanning. Would prefer EEPROM on MCU for this. Should not require JTAG flash to change these.
** Channel config includes bit rate, modulation, power, etc. Everything can be configured per channel.
** These *will* change during competition. Expect frequent changes during setup as other teams go online and crowd us out.
** Too many possible channels to scan in an acceptable amount of time.
* Each robot will scan for the host among the channels it knows on power-on and when it has received no radio data in some period of time (5s?).
** Expect to wait at least 3 radio cycles (33ms) on each channel. If we miss three forward packets in a row, either the host is on another channel or the channel is unusable.
* Not sure how to select a channel for standalone mode.
** Use last channel assigned by host, stored on the base
** Select with joystick
** Clear Channel Assessment (find lowest noise among configured channels)

=Scanning=
Looking for robots that are turned on.
* This should be done per request of the host. Most likely during a ''stop/halt'' in gameplay because we do not reverse channel data then.
* Should be able to change a robot on the field without touching the computer.

=Protocols=
==Forward==

==Reverse==
Under normal operating conditions the reverse channel has several different modes of operation.

# Gameplay Mode
#* Slow Update: All robots are reporting back every ''nth robot'' fast loop interval.
#* Fast Update: Only one robot is reporting back, but is reporting every fast loop.
# Fast Engineering data
# Slow Engineering data

===Information Types===
There are three types of information that need to come back over the reverse channel. They are in order of priority.

====Gameplay====
Gameplay information needs to be updated frequently and is critical to good gameplay.
* Ball Presence
* Capacitor Voltage

====Fast Engineering====
These are things that we want to know periodically, but are not updated very quickly or are not critical to gameplay.
* Battery Health/Voltage
* RSSI

====Slow Engineeting====
Items that do not change at all or change very slowly during a match.
* Board serial number

User:BenJ

2006-07-02T16:18:14Z

BenJ:

'''Name:''' Ben Johnson

'''E-mail:''' [mailto:circuitben@gmail.com circuitben@gmail.com]

'''Web site:''' [http://www.circuitben.net www.circuitben.net]

'''Major:''' Computer Engineering

'''Phone:''' (404) 642-0329