0

I'm working on FLL mission and every time our team launches the robot (without changing the program, and we are making sure that it is starting from same location every time) it is not following the same turns and distance.

Any idea what is going wrong?

  • Can you give at least an overview of what are you trying to achieve and what is the current approach you are using? Even better would be a copy of the actual program (for debugging purposes - the competition is another matter). – zovits Nov 4 '15 at 20:05
  • sure... so we are trying to 1. make the robot start from south wall of FFL table and x degree straight 2. turn right y degree using one large motor 3. go straight z degrees straight after turning 4. come back all the way to south wall by tracing back step 3, 2 & 1 – Im Xyz Nov 4 '15 at 21:08
  • we are using EV3 Mindstorm software, which is a drag and drop programming like scratch .... not sure how to attach code here. – Im Xyz Nov 4 '15 at 21:16
  • You can take a screenshot of your program and post the image. Also see bricks.stackexchange.com/questions/6209/… – David Lechner Nov 5 '15 at 4:49
  • 1
    @ImXyz please edit your steps, code, and any other details into the original question so that it is more complete – chicks Nov 6 '15 at 15:37
2

This is actually a fairly typical problem, with several possible causes.

The motors do not directly drive the axle, there is a gear train hiding inside the plastic casing. That gear train can be deflected without turning the motor.

The software controlling the motor maintains a last known position so that several move blocks can be run in sequence and the over/under at the transition between blocks is taken into account. This is typically a problem when the robot is picked up during an aborted run, and the program is rerun. The robot acts like it remembers the previous run and twitches to the left or right when it is restarted. There is a motor reset block to handle this problem.

Reset rotation sensors for motor A

Dirt/dust on the wheels can also cause issues, as can wheels not firmly positioned on the hubs. This year we spent a whole session trying to get the robot to go straight and ended up trading wheel/hubs until we found a pair that worked fairly well.

Some wheel/hub combinations slip. We spent a long time thinking some old yellow hub + shiny black wheels would work. What a mistake. The wheels didn't slip at first. After a couple runs that smacked into the wall and they loosened and nothing, not rubber bands, not different hubs, not ...

The big message isn't to find a combination that goes straight. Expect it to wander.

  • Thanks for the tip, We are resetting all the motors and sensors after each step and that have improved the reliability of the runs... – Im Xyz Nov 10 '15 at 22:12
  • can you please post a picture of this reset block for the motors? We are having the same issues - frustrating – cal Apr 19 '17 at 17:19
0

If you are using a wheeled robot, make sure that the wheels aren't disturbed in any way. If they move slightly on the axel or the tyre changes position on the rim, turns well be off and in a long program without calibration points, the problem vill propagate and get worse for each turn.

However, this should not affect distances.

0

We have this problem all the time too, very frustrating... We have found that the robot is very sensitive to the charging level of the battery. Keep the battery well charged at all time - seems to help...

Best solution is probably to use sensors to keep track of where on the FLL table you are.

  • We are resetting all the motors and sensors after each step and that have improved the reliability of the runs.. we created myBlock with the reset of all the motors and sensors.... and added my bloc after each step – Im Xyz Nov 10 '15 at 22:14
  • Very interesting! We will definitely try this. Thx for sharing. – Lasse Nov 11 '15 at 22:22
  • You write "We are resetting all the motors and sensors..." - do you use the motor rotation sensor block to reset the motors? It's the only way I find to reset a motor... – Lasse Feb 2 '16 at 13:17
0

In addition to the suggestions already mentioned, we discovered a very unexpected problem causing our inconsistency. Ultimately we found the problem was because the robot was moving a motor though there was no instruction to move the motor in the program at that time. During a turn, the medium motor pushed an arm down on the table, increasing the friction during the turn. Because the arm was already resting on the table, this change in pressure wasn't visible, but the result was significant, as the angle of the turn would often vary by 5-10 degrees. This movement of the arm was noticed only when the program was accidentally run while someone was holding it.

After deleting the program from the robot, changing the program then reloading it, the motor was not moving the arm and the turn was consistent again.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.