# Problem in modelling this because too slow calculation (robot football)

I like to build a component connector view / UML diagram for the given problem but I realized it's way too slow if you try to do it exactly as it's given in the following text. My question is what could be optimized? Knowing this I would create the entire diagram myself.

We have 2 teams playing against each other and the aim is that one team scores more goals than the other. Both teams have the same private ressources: 3 robots, a CPU which is able to communicate with each robot bidirectionally but is also able to send broadcasting messages to all robots of its own team. Every robot has its unique circular pattern made up by CMYK colors (4 colors: cyan, magenta, yellow, black) such that it's impossible they can be confused by the soccer field (green) or with other colors (the ball which is orange).

Both teams share the following shared ressources:

• soccer field: all actions are executed here which allows fluent robot movements. the field is green except for some white colored marks. a 200cm x 100cm rectangle limits the playing surface where the white marked areas (the midpoint, the gateway signs etc.) aren't of importance here

• gateways: on both short sides of the rectangle the middle 40cm-line is covered by invisible sensors. Whenever these sensors detect the ball which crossed the line, the corresponding team gets 1 goal score

• ball: has orange color, robots run to the ball to shoot it into the opponent goal

• host computer: detects the game-events such as ball leaves the field or a goal is achieved. All these events are sent to both CPU's (of the teams) at the same time

• camera: is recording the entire soccer field und sends them to both CPUs of the team. The camera makes 4 pictures every second (so 1 pic each 250ms)

The task of the team CPUs is to determine all positions of robots and ball and also to develop a strategy for the game to inform the robots about it. In order to determine the positions of robots and ball, the CPU needs to process each picture made by the camera, using 4 filters because there are 4 colors (CMYK). Another filter is needed for the orange colored ball. These filters are available for the CPU. But these filters are smaller than the picture taken by the camer: they can only filter 1/3 of it simultaneously. Additionally, each filter needs 500ms to complete all calculations.

The main problem I see here is that the filter needs 500*4*3=6000ms=6s so much time just to determine the positions of the robots, only for 1 picture...! This makes everything else inefficient and the game seems completely unplayable : / How could this be made much faster? I think if I know that I could create the complete component connector view / UML diagram for the problem.

• Find ball. Find goal. Kick and hope. – candied_orange Dec 18 '18 at 21:21
• Is the CPU capable of multicore processing? Are you using up all cores? How much of those 500ms are due to downloading the image files instead of image processing? Maybe you can download the images in parallel/asynchronously? How much control do you have over the robot design? Can you add some preprocessing on the robot itself? – Lie Ryan Dec 20 '18 at 7:26

I would suggest the following.

1. Before the match starts take as long as you like to figure out where your robots are
2. Now you know how fast your robots move and where they started. You don't need to check the whole picture or identify individual robots. If you see A robot and its where you expect it to be you're good.
3. resample the picture and only take every 3rd pixel. Now your filter covers the whole field.
4. You probably don't need to use all the filters, there are only 6 robots in the game.
5. 500ms is still a very long time.
6. the fastest thing on the pitch will probably be the ball. find it quickly, twice, and work out where its going to be and send the robots there.

Update

OMG, I don't know how this post got any up-votes. I cringe a bit when I re-read it. I must admit I came home from a late Christmas/early New Year's party and really drunk while keeping the screen left on SE, only to get tempted to use it while extremely intoxicated. I have a bad habit of being completely unfiltered and just saying the first thing that pops into mind when drunk. It's kind of embarrassing but I enjoy drinking too much to give it up, but I should try not to use SE when I'm not sober.

That said, maybe some of it is relevant. I'm wondering if, besides tuning these filters (and using sampling methods that cover multiple pixels at once as a very nice suggestion from Ewan), you might be able to parallelize them (either paralellize the code implementing them or, simpler, unless they need each other's outputs, parallelize running the filters). I don't know what kind of hardware or API restrictions you're working with, but those kinds of times seem really unusable to me and I'd really reach for a profiler to drill down exactly on what sort of lines the times are spent and why (cache misses, etc).