Closed CalvinTMurray closed 10 years ago
I will be working on that from tomorrow, however I will need a tour in the strategy system.
Main issue (assuming that Calvin's code is right, good idea to give it a look through just in case, it was written overnight, so funky stuff might have happened :P) is probably setting the right threshold value for "safe distance from the white line".
Once we know that method is doing the Right Thing, then it should be integrated in goTo(), quickGoTo() and goDiagonallyTo() [-these are the methods we use for telling the robot to move] to automatically fix any issues with trying to go too close to the white line.
I was looking into this problem, however, I won't be able to work on it as much as I want in the following days. If someone is willing to look into the problem, we can work together on it.
This is still somewhat of a problem. Can somebody check the rules, get a clear idea of how much we're allowed to cross over and report back here? @kocikocev, @mkirova, @Claudiu23 or... anyone really :D If the rules are strict about us not crossing, then we need to do something about it ASAP!!!
To sum up (what I understand): we're allowed to step ON the white line, but NOT go OVER it. Here's what it says:
"The robots cannot extend over the central lines that divide the zones with any part of their bodies. They are though allowed to step on the surrounding tape and/or have part of the robots on them. If a robot goes beyond their assigned zone, then the ball may be given to the other team, or a free kick or a penalty kick to the discretion of the referee may be awarded against the team doing the foul.The o ending robot may also be sin-binned for a period of 10-30 seconds." On Sunday, March 30, 2014 5:57 AM, andretamm notifications@github.com wrote:
This is still somewhat of a problem. Can somebody check the rules, get a clear idea of how much we're allowed to cross over and report back here? @kocikocev, @mkirova, @Claudiu23 or... anyone really :D If the rules are strict about us not crossing, then we need to do something about it ASAP!!! — Reply to this email directly or view it on GitHub.
I looked over the emails and I can't finds anything mentioning crossing the white line. I have found the same info as Claudiu regarding the rules. I thing it is best to restrict the defender not to go for very difficult balls, that is when the ball is just on the line. It is better to not do anything, and let them restart the play, rather than having our defender be removed from the pitch. As for the attacker we can play slightly more risky, allowing it to go for difficult balls.
In the method goTo, it seems we are currently using the safePoint. @andretamm can you tell me if you have tested the movement with the safePoint or we are currently not using it?
As we talked at the team meeting (and later verified in the code), the answer is yes :D we don't see it trigger too often though, so worth rechecking it's right. Konstantin is working on this now.
I looked at the code for the safe point, and refactored it. However, later when I added a display of the actual points I am trying to go to and the safe point, I noticed that this should actually set back the strategy for getting the ball, making it even more difficult to grab the ball. I didn't achieve any considerable progress, and this issue is still opened. I will report with the new things I will hopefully figure out today.
On Sun, Mar 30, 2014 at 9:01 PM, andretamm notifications@github.com wrote:
As we talked at the team meeting (and later verified in the code), the answer is yes :D we don't see it trigger too often though, so worth rechecking it's right. Konstantin is working on this now.
Reply to this email directly or view it on GitHubhttps://github.com/andretamm/sdpwinners/issues/23#issuecomment-39037470 .
@andretamm I have an idea about safely moving to the ball and I want to see what do you think. You know how I showed you the two lines to the ball and to safe point. Can we add a new behaviour in our defender code, at the highest priority and the behaviour is that we first go the safe point and from there we start running the old strategy for grabbing the ball. That would allow the robot to approach the ball from slightly less akward angles and will result in only the grabber going slightly over the line.
The problem was caused when the defender or attacker tried defending at a high movement speed (and not when grabbing the ball, since we use a low movement speed there), causing stop commands to be sent too late when the robot headed off in a direction towards the white line.
This was fixed by: a) Moving the defender's defending line closer to the goal b) Slightly lowering the speed on the defender c) Lowering the speed on the attacker by 40% when defending since the attacker doesn't have a wall to stop it from going over the line on one side, so it was in danger of crossing over white lines on both sides. d) Manually changing the values in the sine and cosine lookup tables to stop movements at small angles from using all four wheels. What would happen is that since the i2c board has a "minimum movement speed" lower than which it can't move the wheels, when trying to move at a small angle (meaning 2 of the wheels would have very slow speeds), they would instead move too fast, often resulting in us going towards the white line too fast and crossing it. By disabling movement of the two "slow" wheels on small angles (7 degrees around 0', 90', 180' and 270'), we reduced the number of these imprecise movements.
This will reduce the amount of fouls we commit in matches. Specifically the defender robot!!