Final Competition- Robosoccer

With the final Robosoccer being due on 12/22, our design and implementation needed to be finished and ready for competition on this date.  Needless to say, we smoked the competition, winning by a score of 2-1 that was really never as close as the score indicated.  The final report for this project is listed as a document on this blog, and details of the system level architecture are presented and described in full.  Overall, this was a very successful project and a great lesson in system integration.  It would make for a successful future project if expanded to many more teams, each of which needed to design and bring their own team of robosoccer players to game-day ready to play in a tournament.

All of the completed components sitting on the game-board next to our goal

current status and wiring pictures

Goalie AI works really well. Player controls are iffy, but we probably just need more practice.

Controller Redesign

The controller code for the game has been completely redesigned and is now based on 1 accelerometer and 2 buttons.  The two buttons handle throttle and reverse,  while the accelerometer is used for turning purposes.  What this allows for is for the user to have tactile feedback for his throttle, and not have to work about dipping his controller both forward and to the left or right.  With that prior method, the sensor values would not produce good results when the camera was dipped in both directions.  Now, the controller can receive good readings for 1 axis of turning, and the robot is more responsive to the user’s input.

Robosoccer- Rebooted

Black electrical tape used to mark off goalie boxes, goal-kick zones for offense and defense, midfield, and zones for both offense and defensive interaction.

New soccer field design.

Goalie Robot

The goalie robot has been designed with a removable LED identifier, created with three LED’s and a half-ping-pong ball dome to diffuse the light.  The goalie will be autonomously controlled by the CMU Cam, wirelessly, and will patrol the front of the goal, and seek out balls when they enter the goalie box.

3pibot + LED's + firefly

The goalie is designed with a 3pi robot, connected to a firefly node via serial port, with an array of LED's on top, diffused by a ping pong ball.

New CMUCam Mount

Beam and vice used to mount the cmucam and firefly node above the board

The High Hide is gone, sadly, however we have found a new, and practical mount for the CMUCam and associated firefly node.  Each of these will extend from the work benches to either side of the field.  They are placed high enough such that they can see about 40% of the board, however they are still low enough such that the resolution can make out the 3Pi robots, and will be able to more accurately control the goalie now.

PROJECT CHANGES

Because of the difficulties experienced with using CMUCam as an overhead environment monitor, the structure of the project has changed to play more to the strengths of the camera.  The game will now be played as follows:

2 soccer players per team, controlled wirelessly via Firefly nodes and accelerometer-based controllers

1 soccer goalie, using the 3pi robot and CMUCam.  The goalie will be autonomous and have the job of tracking the ball via CMUCam when it comes close and preventing it from entering the goal.

We will possibly still be implementing the GUI to keep track of the score, and depending on whether the CMUCam can effectively view HALF the field while controlling the goalie, we will still provide some sort of player positioning if each camera can monitor half the field and update the GUI sensor node.

More CMUCam Exposure Register Info

Register 24- rw: AEC Auto Exposure White Pixel Ratio


Registers 24 and 25 together control the AEC target values for image brightness.
For a brighter image, increase register 24 and decrease register 25.
For a darker image, decrease register 24 and decrease register 25.
AEW<7:0>- used to calculate the white pixel ratio. OV7620 AEC algorithm counts the
whole field/frame white pixel (its luminance level is higher than a fixed level) and black
pixel (its luminance level is lower than a fixed level) number. When white/black pixel ratio
is same as the ratio defined by registers [25] and [26], image stable. This register is used
to define the white pixel ratio, default is 25%, each LSB represent step: Interlaced: 1.3%;
Progressive Scan: 0.7%. Change range is: Interlaced: [01] ~ [4A]; Progressive Scan: [01]
~ [96]. Increase AEW<7:0> will increase the white pixel ratio. For same light condition,
the image brightness will increase if AEW<7:0> increase.
Note: AEW<7:0> must combined with register [26] AEB<7:0>. Keep the relation always
true: AEW<7:0> + AEB<7:0> > [4A] for Interlaced; AEW<7:0> + AEB<7:0> > [90].

Register 25- rw: AEC Auto Exposure Black Pixel Ratio


AEB<7:0>- used to calculate the black pixel ratio. OV7620 AEC algorithm is count whole
field/frame white pixel (its luminance level is higher than a fixed level) and black pixel (its
luminance level is lower than a fixed level) number. When white/black pixel ratio is same
as the ratio defined by registers [25] and [26], image stable. This register is used to
define black pixel ratio, default is 75%, each LSB represent step: Interlaced: 1.3%;
Progressive Scan: 0.7%. Change range is: Interlaced: [01] ~ [4A]; Progressive Scan: [01]
~ [96]. Increase AEB<7:0> will increase black pixel ratio. For same light condition, the
image brightness will decrease if AEB<7:0> increase.
Note: AEB<7:0> must combined with register [25] AEW<7:0>. Keep the relation always
true: AEW<7:0> + AEB<7:0> > [4D] for Interlaced; AEW<7:0> + AEB<7:0> > [90].

CMU Cam Low Level Register Info:

This register info may be necessary for changing the exposure settings on the CMUCam.  It seems you need to modify its low level registers in order to change the exposure settings.  Despite using ultrabright LED’s and diffusing them with half-pinpong ball coverings, the tip of the LED is still too bright.  This issue could possibly be solved by turning down the exposure of the camera, and reducing the amount of sensor saturation that occurs.  This could also help eliminate noise in the gameboard, and lend itself to using LED’s to mark other significant properties.

——————————————————————————

CMUCam CR Register-

CR [ reg1 value1 [reg2 value2 … reg16 value16] ]\r

This command sets the Camera’s internal Register values directly. The
register locations and possible settings can be found in the Omnivision
CMOS camera documentation. All the data sent to this command should
be in decimal visible character form unless the camera has previously
been set into raw mode. It is possible to send up to 16 register-value
combinations. Previous register settings are not reset between CR calls;
however, you may overwrite previous settings. Calling this command with
no arguments resets the camera and restores the camera registers to their
default state. This command can be used to hard code gain values or
manipulate other low level image properties.

Register 10 – rw: Auto-Exposure-Control Register

AEC<7:0> – exposure time setting; the formula is Interlaced: TEXPOSURE = TLINE x
AEC(7:0); Progressive: TEXPOSURE = TLINE x AEC(7:0)x2; where TLINE = Frame Time /

* This register setting is only effective when operated in manual adjust mode (register 13
bit 0=0). Nevertheless, this register is always accessible through the SCCB bus. If
register 13 bit 0=1, this register will be updated by internal circuit according AEC
algorithm, and if write special value to this register will be useless. The register value can
be read out at any time and latest AEC value will be return. If register 13 bit 0=0, or
register 29 bit 7=1, the register will hold last value unchanged (either input from SCCB or
AEC algorithm result).
It generally takes no more than two fields for the image to reach the intended exposure
after changing the setting.

Gameboard Boundary Identification

This function might be useful in identifying the boundaries of the gameboard.  It could create a mask that we can use to identify what coordinates are valid and what coordinates are not valid.  Could also be useful because we could use the function to calibrate the gameboard mask every run and adapt the valid and invalid coordinates for each game.

http://www.cmucam.org/wiki/polly