I've created an issue to debate the necessity of Max Bot's rotating kicker, let's get this sorted by Wed 26/03/14

Divide processing into four quadrants and only look for a specific robot in each quadrant. Note that finding the ball still needs to use the whole image.

This issue needs to be completed before #12 can be started.

What normally happens when we rotate -

1. send rotate command to robot
2. robot starts rotating
3. we see from the vision the robot is about to be at the right position
4. send pre-emptive stop, knowing it will arrive with a delay
5. robot gets stop and kind of stops at the right place

The above is okay when we need to get the ball, because a) we have time b) the ball moves around a lot. But when attacking we want speed and precision! Without further ado, let me introduce you to Super Ultra Precise Fast Rotation or SUPFR:

1. Send rotate command together with how many degrees to rotate
2. Robot rotates exactly that many degrees, BUT is unresponsive while rotating, stops automagically when done rotating

So plan is to use SUPFR for the attacker when trying to score a goal and the old rotation for everything else.

The diagonal movement is slightly buggy, here are some symptoms we have been seeing:

1. While doing diagonal movement the robot beeps (usually two beeps in a row)
2. Quite often the robot resets itself while doing the diagonal movement, going back to the "waiting for connection..." state. This seemed to be happening more with higher speeds (or when the batteries were more full), don't know if related though.

If there appears to be an error with a robot (in a match) provide functionality to easily reconnect to the robot during a match

I am currently working on getting the code from Group 1 2013 communication pack and play around with it to see what it does and how can I make it work for two robots.

• For each quadrant allow separate thresholds for finding the ball, yellow/blue plate, green plate, and grey circles

General framework that will let us easily manage strategies.

Lens distortion causes incorrect world state ball and robot positions! Undistort points using the fix distortion method already present. Another approach could be using open/javaCV, which provides distortion fixes on points.

Want this to be able to guess where the ball is going and how fast it will get there. So should be able to use velocities and histories from the Vision system's world state to do physics magic and tell us where the robot will go.

This should be useful both for helping us defend goals and for letting us make passes between the defender and attacker. Oh and wallkicks from the attacker to the other team's goal :)

Probably going to be some combination of @mkirova and @andretamm.

Shows the target point the robot is moving to and the current instruction it's executing.

This will reduce the amount of fouls we commit in matches. Specifically the defender robot!!

Currently only has ones for the ball and both defender robots.

Sometimes the robot started going round in circles around a target point it wanted to reach when doing diagonal movement. I believe this is because we get the same effect as if a satellite was orbiting a planet, we send it commands to go towards the point (gravity pulling towards the planet), but its existing velocity/inertia is perpendicular to that new direction, so it starts going round in a circle.
Here's an illustration : http://upload.wikimedia.org/wikipedia/commons/4/4e/Orbital_motion.gif

I just ran some code on the design Bagdat came up with. It does just fine running around the pitch with the ball but the release kick is not strong enough or very accurate. Grabbing ahold of the ball was also pretty good.

Currently only ports 1 and 3 work, 2 and 4 seem to be unresponsive. It's also not very fast, need to consult with Garry to see if there's something we can do.

@mbleftley (and @kocikocev) in charge :) 👍

1. Choose a stationary position in the quadrant, aim for the goal, kick left/right
2. While facing the goal move up, aim kicker and shoot
3. Wall kick
   Etc..

Possible reasons for overrotating:

1. Slow Bluetooth
2. VIsion/Strategy system too slow to react that we're in the right spot
3. Robot brakes too slowly

The coordinates of the pitch need to be adjusted/checked for the second pitch, I think they are a bit off right now (I might be wrong, can't check at the other pitch atm).

joihsdgohdsgoih

• Possible use of mean shift algorithm
• Use threads to search for ball, and one robot plate in each quadrant
• Update world state for ball position and Yellow/Blue Attacker/Defender Robot

Right now we utterly fail detecting the green plate in the bottom bit of the pitch in the second room.

Possible solutions -

1. Using background subtraction! I think this is a potentially insanely powerful tool that we haven't used yet.
2. Some kind of clustering algorithm

@CszMurray and @mkirova are in charge of this. This needs to be done and working by Tuesday latest so we can already test on Tuesday afternoon, possibly make some small fixes and then freeze the code on Wednesday.

I have updated the world state, to include an attacker and defender robot for yellow and blue teams. Method name calls need to be changed to allow the main class in the vision package to run.

Enhance the kicker of the MaxBot to score goals using a wall kick strategy.

1. Ask gary if there is any stronger motors (but not larger) that could be used for this task.
2. Double the number of gears on the kicker

I felt left out by all the emails I have been getting about issues. So I want to make one as well. Lots of Love.