Announcement

Collapse
No announcement yet.

EV3 Large Motors not synching?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • EV3 Large Motors not synching?

    We have two teams working with EV3's. Each team has 2 identical robots--so 2 pairs of 2 unique designs. All 4 robots are seeing the same issue. None can go straight. They all seem to lurch when starting, and the motors appear to be out of synch and you can see them trying to compensate. Over a course of ~30", they will lurch back and forth for about 10" and then go straight for the last half or so, but are off course from the original starting point, of course.

    We are using larger wheels. Changing to smaller wheels helped initially, but one team is seeing the issue again.

    Has anyone else run into this?
    Sylvania STEM Center Coordinator
    Twisted Toys
    Trash Trek--Coach
    World Class--Coach
    Nature's Fury--Coach
    Senior Solutions--Coach
    Food Factor-Coach

  • #2
    Re: EV3 Large Motors not synching?

    It is pretty common with NXT, so it doesn't surprise me that it is also happening with EV3. Is it a motor problem, a programming problem, or a mechanical problem? A lot of problems blamed on mismatched motors or poor PID tuning end up being a mechanical design flaw.

    Do the robots run smoother if they drive backward? If so this could indicate a weight distribution problem. Tippy robots do not perform well.

    What happens if you run the motors independent (not using steer or tank block)? With my robot it is hard to tell any difference between independent, steer or tank control. All go pretty straight with a very slight wobble.

    What happens if you use unregulated motor blocks. How much does it curve. My robot using the education set wheels and a 5" track curves to the left at about a 20' turning radius. If yours curves a lot more than that you might try some motor matching experiments.

    Switch the motor wires (If A was left and D was right swap so A is right and D is left). Are you off course in the opposite direction or the same direction? If the course deviation switches sides you might have a wire, a port or a program problem. Try using different ports. Try using different wires. If the course deviation doesn't switch sides you could have a motor, wheel, or mechanical problem.


    Switch the left and right wheel. Anything change? I don't know how many times I've seen strange robot behaviors tracked down to a tire that is not seated well on the wheel.

    If possible switch motors (swap left and right motors). Are you off course in the opposite direction or the same direction? If the course deviation switches you have some motor imbalance. If the course deviation doesn't switch I'd start looking for something broken in my robot. Are the axles well supported? Is anything getting pinched? Are the wheels properly aligned?

    It is challenges like this, not the robot game, that are more interesting and rewarding to solve. Be thankful for roadblocks.
    Last edited by Dean Hystad; 10-05-2013, 10:33 PM.

    Comment


    • #3
      Re: EV3 Large Motors not synching?

      In my experience, I have found that larger wheels do tend to make it difficult to move precisely. For starters, the motor does not need to rotate as many degrees to get the robot to move a certain distance which means that a small adjustment to the motor position will result in a large movement in the robot. Larger wheels require more torque to get the robot moving. Also, when stopping, larger wheels can apply torque from the momentum built up by the speed of the robot resulting in robots that stop beyond their desired position (that's why sometimes the robot has to back up to compensate). In general, a smaller wheel will give you more precise movement. However, there is a trade-off between precision and speed. A robot with smaller wheels tends to move slower than one with bigger wheels (for obvious reasons).

      At tournaments you will see teams with robots that have large wheels zipping around the board while other teams with smaller wheels are moving at a more deliberate pace. While the robots with larger wheels may move faster, they may have trouble knowing when and where to stop.

      Don't give up on the big wheels just yet. I think the solution has to be in making sure the robot is aware of where it is on the board and where it needs to be. Use the walls to align the robot square with the game board. Use the light sensor to detect when it has crossed a line.

      As for the problem with "lurching when starting", I think that has to do with the power level. Don't start at 100% power from a dead stop. Try to gradually accelerate to the desired speed. But implementing an acceleration block may be a challenge. You could just start with a lower power level. But this would only bring you back to a large wheeled robot that moves at the pace of a smaller wheeled robot.

      Try to accept that the robot may not go perfectly straight. Use the wall to help the robot move straightly. For example, going from base to the airplane or from base to the dog, you can ride up against the wall (which is by nature straight). When you need to get to the middle of the board or to a wall across the board, backup up against the wall first to make sure the robot is pointed in the right direction, then try to make as few turns as possible to get to your destination.

      A large wheeled robot that uses sensors and walls should be able to maneuver well around the board.

      Comment


      • #4
        Re: EV3 Large Motors not synching?

        Thanks for the replies. The kids were starting btw 30% and 50% because of the potential startup torque issue. They used large wheels last year to great effect with the NXT. They do use sensors and square up on a wall whenever they can and are going to start with lining up on lines (hopefully) this year.
        Sylvania STEM Center Coordinator
        Twisted Toys
        Trash Trek--Coach
        World Class--Coach
        Nature's Fury--Coach
        Senior Solutions--Coach
        Food Factor-Coach

        Comment


        • #5
          Re: EV3 Large Motors not synching?

          What do you mean by "starting btw 30% and 50%" ? Do they change motor power during the move? When and how? Is startup torque an issue or is it just a "potential" issue?

          The more I think about it the more I am lead to believe the problem is in the programming. Four robots don't have horribly mismatched motors or bad wires or binding axles or tires falling off the wheels. Sure it's possible that the two teams are using similar mechanical designs that have the same flaws, but I think it much more likely they are using the same flawed software design to control motor power and that is what's causing the wobbly behavior.
          Last edited by Dean Hystad; 10-06-2013, 07:57 AM.

          Comment


          • #6
            Re: EV3 Large Motors not synching?

            I ran a bunch of large motor control tests over the weekend and the performance is pretty good. Over several 1 meter straight runs the maximum Left - Right tracking error was 10 degrees. Most runs had less tracking error, and the maximum tracking error for each run was an isolated spike. Tracking error for almost all of the run was in the +/- 1 degree range. Unlike NXT I was unable to get better performance using my own PID to close the loop.

            Ramping power is easier in EV3. In NXT-G putting a Move block inside a loop usually resulted in a noticeably curved trajectory. I did not notice this behavior in EV3. Breaking the ramp into 100 small steps resulted in no more motor sync error than using a single motor steer block.

            A few caveats. I only have one EV3 and two large motors. Not a good sample size. It is certainly possible that my system is on the good end of the bell curve. I ran most of my tests with the robot upside down and the wheels spinning in air. For NXT-G this was usually the worst case scenario. This may not be true for EV3, but my few rolling tests matched up well with open air tests. A small error for most of the run with one or two isolated peaks (max error in a rolling test was 5 degrees).

            My robot uses the 56mm wheels that come in the education version. The track is 450 mm. The robot has no noticeable sag in the middle and wheels are cantilevered, but the axle is supported in two places. I use the ball caster for balance.

            Comment


            • #7
              Re: EV3 Large Motors not synching?

              I ran some additional sync tests with continuous power ramping (move block is inside a loop with that recalculates power continuously throughout the move). For this test I had the robot drive out 2 meters and drive back 2 meters. I measured the difference between the starting and ending position.

              Forward/backward variation
              Average for 10 runs less than 0.5 cm
              Max error less than 1 cm

              Side to side variation
              Average for 10 runs less than 0.5 cm
              Average error 2.5 cm
              Max error = 11.5 cm

              I chose the forward/backward test because I cannot line up the robot accurately. Variation at the outward via point was much greater than that measured upon return. That means my aiming error was far worse than any error produced by the motors not synchronizing.

              Comment


              • #8
                Re: EV3 Large Motors not synching?

                In my observation the EV3 is equal to or better than NXT when it comes to matching motors. The kids even put the steering block and tank blocks inside loops without invoking some of the bugs NXT exhibits with respect to the old Move Block. I am assuming here your kids are using the steering or tanks blocks and not doing anything open loop with separate motor blocks. And I'm also assuming you are using the new EV3 motors. We did a trial robot with old motors NXT motors and EV3, and it also seemed to work fine, but they didn't carry out extensive experiments.

                In addition to the mechanical suggestions from others: my kids eventually noticed that some of what they were seeing was gear backlash in the motors themselves. And got in the habit of making sure they did enough "bumps" into things at low power to take out all the slack in the gear train before major moves that needed good accuracy. Last year they were so convinced it was a bad motor I let them cut one open (NXT era motor here) and look at the gear train. The encoder is way up near the motor, not at the end of the reduction line. So all the slop of those little plastic gears is there when you start up. they thought it worked out to 5-8 degrees of shaft motion per motor. I think that's high, but it's certainly not zero.
                Team M
                Coach

                Comment


                • #9
                  We have two large motors for driving and one for the arm. The motors appear imbalanced and pulls to one side when driving fast a distance. Is the recommended correction a gyro? Or are there other methods we should be looking at?

                  Comment


                  • #10
                    There are lots of reasons a robot may pull to one side. There could be more friction on one side. There might be more mass on one side. The motors may not have the same performance. Some imbalance is normal. Without any details I cannot say if what you are seeing is normal or not.
                    Last edited by Dean Hystad; 09-24-2017, 09:40 PM.

                    Comment


                    • #11
                      Some EV3 or EV3-motors seems to be buggy. See the video https://www.youtube.com/watch?v=YTJrs1DTx2E
                      I sent an email to lego and waiting to hear from them.

                      Comment


                      • #12
                        Originally posted by laplacia View Post
                        Some EV3 or EV3-motors seems to be buggy. See the video https://www.youtube.com/watch?v=YTJrs1DTx2E
                        I sent an email to lego and waiting to hear from them.
                        The problem in the video is puzzling. It took a while to understand why one motor would spin faster than the other and this would change from run to run. But before I talk about that I want to talk about serendipity. Right after watching the video in the link YouTube decided to show me a video about an actual motor problem and how confusing and counter-intuitive these kind of problems can be.

                        https://www.youtube.com/watch?v=bsA2N7a34cY

                        In this video the problem is caused by a bad encoder in the motor that spins freely. This is immediately obvious to someone with experience in closed loop control, but I think most people would have the same thoughts expressed in the video. The spinning motor is spinning, just like we asked. The stationary or creeping motor is doing something odd. The problem must be the motor doing something odd. I'ts obvious, right? Here is why intuition not backed up by knowledge doesn't work.

                        The move block adjusts the power to the motors to keep their motion synchronized. But what does it mean to be synchronized, and how does it adjust power? The brick cannot visually see that the motors are spinning at the same speed. It has to rely on the rotation sensor feedback. The brick compares the feedback of the B and C motors and if the B motor is ahead of the C motor the power to the B motor is reduced and the power to the C motor is increased. When you see a motor that is barely crawling along that is supposed to be synchronized with a motor that is spinning like crazy, the problem is with the motor that is spinning like crazy. That motor is telling the brick that it is not moving. There is a a problem with the encoder in the motor that measures the motor motion, or a problem with the wire that doesn't pass the encoder information back to the brick.. Because the brick is not told the motor is moving it sends more power to that motor and less power to the motor that actually works. You can easily test the encoder by manually spinning the motor and looking at the rotation sensor feedback in the port view. If the motor is moving but the rotation sensor feedback doesn't change the brick isn't getting any feedback. Before tossing the motor test it with a different cable because the problem could be a broken wire in the cable.

                        Back to the original video. This is not the problem in the original video. A bad encoder does not go away and reappear from one run to the next. A broken encoder mount inside the motor may result in a motor that works some of the time. I've seen motors that work mounted one way but failed when mounted upside down, or motors that work until a collision then stop working. A bad wire may work when there is it is straight but not when it is bent. Nothing like this happened in the original video. In the video the motors work some times and not at others and there are no differences other than different runs of the same program. Plus the second motor in the video appears unaffected. When you have a bad encoder the brick compensates by slowing the good motor down while the bad motor spins like crazy.. In the video the second motor always moves the same each time they run the program.

                        A second motor problem is that the brick may misidentify the motor type. If the software thinks a large motor is a medium motor it will send the wrong power to the motor and the motor will run at the wrong speed. If your robot usually drives straight but one day it starts driving in a very pronounced curve, this could be the culprit. You can verify this by looking at port view and checking the picture for each of the motors. If you are using a large motor and the port view shows a medium motor the motor was misidentified when attached or when the brick was powered on. You can fix the problem by unplugging the motor wire and plugging it back in again. This makes the brick go through the device identification again. I cannot make this happen with my motors and wires, but it has been widely reported. Again, this cannot be the cause of what is happening in the original video. The speed difference between the motors matches the behavior, but restarting a program does not force a device identification, so running the program cannot make this problem appear and disappear.

                        I am going to fall back on programming. Programming is the cause for 99.9% of these kinds of strange problems. It is difficult to reproduce the program from the blurry screen images (just what is that going on directly above the download and run buttons?), but I took a stab at it and got something that exhibited similar behavior.

                        Capture.JPG

                        Run this program and sometimes the motors run in little jerky steps, sometimes the motors spin at 50, and sometimes it starts with jerky steps and then begins to spin freely. On my computer it was always motor C that ran fast, Even if I swapped the wires so the left motor was the C motor instead of the right, When I ran with motors attached to B and D or C and D it was always the higher drive letter that breaks away and runs faster. Interesting.

                        This is not a motor problem. Depending on your view this is a programming problem in the EV3 motor control software or in the user's program. Guess which way I lean. The program asks the motors to spin 5 degrees over and over and over while remaining synchronized. During a move the EV3 brick synchronizes motors by adjusting power to the left and right motors to keep the motors turning at the same speed. The EV3 also does something interesting when you run a sequence of fixed duration moves. If there is any motion between moves, like moving a motor by hand or allowing it to coast, the move block tries to compensate by adjusting the duration of the next move. FLL teams that write mission sequencers discover this when their missions run differently in the sequencer than they do when run as independent programs. What we have in this program is a condition where the motor synchronization and move duration correction are battling it and neither really works. The motors are trying to sync, but they don't have any time to do so. The moves are trying to correct, but there are so many starts and stops. If I disable either correction, the strange behavior goes away. If I increase the duration to 20 degrees the motors remain synchronized though the motion is jerky and it sounds terrible. If I turn off the "between move" compensation by resetting the motor after each move (using a move stop block) I no longer get the runaway behavior.

                        Capture3.JPG

                        If you want to use the move blocks and you want the motors to synchronize you cannot do a bunch of little moves. We cannot have the move synchronization and duration compensation fighting. The proper way to do what I think they wanted in the original video is to start the motors and allow them to run until a button is pressed.

                        Capture2.JPG
                        Last edited by Dean Hystad; 03-06-2018, 09:31 AM.

                        Comment


                        • #13
                          When you say things like "intuition not backed up by knowledge doesn't work" you better have intuition and knowledge. I decided to take a closer look at what the motors do when a disturbance knocks them out of sync. I ran a program that runs the motors at power 25 and collects the B and C degrees as well as B - C. While the test ran I would grab the C wheel and stop it. Shortly after the C wheel stops the brick also stops the B wheel. When I release the wheel both wheels resume spinning at speed 25. This is a plot of one run.

                          stall sync data.JPG
                          In this plot the left axis is degrees for B and C motor position. The right axis is degrees difference for B - C. Each time I manually stalled the C motor (the big bumps in the green line) you can see the B-C difference rapidly climbs about 60 degrees before the B motor comes to a stop. When I release the wheel the motors do not snap back into sync. Each time I stall the B motor I increase the B-C difference by about 20 degrees. After the first stop the motors are about 20 degrees out of sync. After the second stop this increases to 40. After the fourth stop the difference is 80 degrees. The amount of "recovery" after a stall differs each time and the difference never goes away.

                          The next step in this experiment is to either deduce from the data how synchronization is performed in the move block or to create a synchronization model that delivers similar results. The data didn't immediately point me to a solution, so I wrote a synchronizer that uses motor position feedback.

                          Correction = (C degrees - B degrees) * gain
                          C power = Move power - Correction
                          B power = Move power + Correction

                          I was pretty sure this wouldn't work, but I already had the code to run the test. When synchronizing using motor position the motor rotation sensors should snap back into sync when I released the wheels. I ran a test and collected data. The plot for one run is shown below.

                          Position Sync.JPG

                          In this plot we see the big bumps in the green trace, but when the C motor is released the B-C difference quickly returns to zero. This is clearly not what happens with the Move block, so the move block must be doing something different.

                          For my next test I synchronized motor power based on the motor speed feedback. The Motor sensor block can return "Current Motor Power", but this value is really the motor speed scaled to +/-100%. Using an integrator I adjusted the left and right power values to make the current motor power feedbacks the same.

                          Correction = Correction + (C current motor power - B current motor power) * gain
                          C power = Move power - Correction
                          B power = Move power + Correction

                          Synchronizing using speed instead of position gives the servo loop a case of amnesia. The servo adjusts for immediate differences in motor speed, but quickly forgets about errors that occurred in the past. Using this technique I expect the motor position to become unsynchronized when the motors stall and remain unsynchronized when the stalled motor is freed. There will be some recovery due to the nature of the integrator, but it won't be completely predictable. I ran the test and collected data. This plot looks a lot more like the original plot

                          Power Sync.JPG

                          Notice how the B-C difference grows each time the motor stalls, just like the synchronization built into the Move block. There is some recovery, but the recover is not complete nor is it completely predictable. You should ignore the noise in the B-C trace for when both motors are spinning. The performance of my motor speed sync servo isn't very good. I could make it much better adding proportional and derivative gains, but the purpose for this experiment is understanding the Move block synchronization, not replacing it. These results are good enough for my purposes. This isn't proof by any means, but it is a good indicator that the Move block synchronization is similar to my speed error integrator model.

                          Synchronizing using speed would explain a lot of strange behaviors. For example, when I pair a large and medium motor in a move block stalling one motor causes the other motor to stop, so there is synchronization, but the two motors spin at very different speeds. The reason for this is the speed feedback for the medium motor is different than the speed feedback for the large motor. 100% speed for the large motor is about 1,000 degrees/second. 100% speed for the medium motor is about 1,500 degrees/second. The motor speed is synchronized, but the motor rotations are not. Speed synchronization could also explain why some robots have a little steer jerk at launch and then drive straight. There are other explanations for the quick jerk, but if my robot was exhibiting this behavior I would collect some rotation sensor data to determine if synchronization was the problem.

                          Just wondering if any of you are finding this interesting. Am I wasting my time posting these results (I'm going to run the experiments anyway), or even worse being an annoying pest? I know there are a few teams that dive really deep and have a thorough understanding of EV3, but my judging experience shows this is depressingly rare. My hope is that my little experiments will demonstrate that experimentation is useful, even fun, and that anyone can be a scientist, make their own discoveries, and not have to depend on others for finding answers.
                          Last edited by Dean Hystad; 03-05-2018, 02:34 PM.

                          Comment


                          • #14
                            Following up on the previous post I ran an experiment to move the motor using 100 steps each 5 degrees First I ran the experiment with no wait between moves, then I repeated the test with a 10 ms delay between each move. This is the program:
                            program.JPG
                            With the wait block set to 0 seconds the motor motion is smooth. With a 10 ms (0.01) delay the motor motion is irregular and jerky. This is shown in the plot below.

                            Plot.JPG
                            The red trace does a good job representing what I saw when I ran the test. The motor appeared to lurch 6 times and stop. The time between lurches was irregular, but much longer than 10 milliseconds. There was a brief period during the test when the motion was smooth and continuous. This was followed by two more lurches and the program was done. Notice that in both cases the motor moved 500 degrees (100 x 5 degree moves). Here is what I think causes the lurching motion.

                            When you perform a fixed duration move it increments an internal motor command. I started talking about this way back when NXT was introduced, and I think EV3 does the same thing. I needed an explanation for why manually moving the robot between move blocks affects the duration of the following move block. The best explanation was this internal command that we cannot see and can only affect using move blocks. This command is zero when you start the program. If you ask the motor to move 20 degrees the command is incremented by 20 degrees. In my test program that calls a 5 degree move block 100 times the internal motor command increments 5 degrees at a time all the way up to 500.

                            When you execute a move block it increments this command and then it rotates the motor until the motor position reaches the command. When the motor reaches the command it is done executing and the program moves on to the next block. The amount the motor has to move depends on two things, the value of the internal command, and the position of the motor. If my first move 5 degrees command actually moves the motor 8 degrees, the second move 5 degrees command only has to move he motor 2 degrees (5 + 5 - 8 = 2). When I have a 10 ms delay between moves and the next action is coast, the motor may move a lot between commands. Sometimes the motor might move so far that it takes a second or so for the internal motor command to "catch up". The lurches and pauses in the red trace are the motor coasting too far and then waiting for the motor command to catch up.

                            So what does this have to do with motors not synchronizing? Imagine that I am commanding to motors to perform a bunch of little steps. The left motor coasts better than the right, or maybe it is more efficient, so it gets ahead of the right motor. We start a new move block and increment the internal command to 50. Unfortunately the left motor is already at 52 and the right motor is at 48. What do we do? Do we wait for the command to catch up with the left motor? We can't run the motors at different speeds because the move block tries to run the motors at the same speed and it doesn't care about the motor positions. The code trying to control the move duration and the code trying to synchronize the motors are at odds and there is no resolution.

                            It might be nice if LEGO rewrote the move blocks to synchronize motors using position feedback. I think the software already has a position control loop that is used to implement electronic braking. Notice that when a motor has the brakes on you can move it slightly, but the motor snaps back to the original position when released. But changing the software to synchronize using position feedback would be a REALLY BIG change. Each time through your servo loop you need to compute a command for the left and right motors. The motors adjust power to make the motor position follow the command and don't worry about left/right sync because if the commands are synced and you follow the commands the motors are in sync. The motors would be really "stiff". Right now you can stall a motor, but if you were using position control the motor would quickly go to full power to try and follow the command. And what do we do if a motor does stall? The command generator would have to detect a stall and hold off advancing the commands until the motors could recover. A lot of changes. A very different behavior. Maybe better, but maybe worse.

                            Instead of asking LEGO to fix what might not even be a problem, why not write programs that the robot can execute. If you want to move using a bunch of tiny steps use two motor blocks instead of a move block. If you want synchronized motion don't move in little steps. The software is pretty capable.
                            Last edited by Dean Hystad; 03-10-2018, 06:41 PM.

                            Comment

                            Working...
                            X