Announcement

Collapse
No announcement yet.

acceleration problem

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

  • acceleration problem

    hello,
    i try to programme an acceleration bloc and I get a very strange behaviour. I use the char/move bloc and both big motors are not acting a the same.
    In my loop, one motor turn two tinmes faster as the other. Do you have any idea ?

    acceleration.jpg
    Last edited by switch; 09-16-2013, 05:00 AM.
    My youtube channel

  • #2
    Re: acceleration problem

    Originally posted by switch View Post
    hello,
    i try to programme an acceleration bloc and I get a very strange behaviour. I use the char/move bloc and both big motors are not acting a the same.
    In my loop, one motor turn two tinmes faster as the other. Do you have any idea ?
    I see two possible problems.

    1. The first Compare block uses ">" and that should be "<". The first time, the speed will be 45 and subsequent loops, speed will be increase by 10.

    2. Change the Move block to "ON" instead of "ON for Degrees". The "On for degrees" will cause the motors to move/stop repeatedly and I suspect you want a smooth acceleration.
    Tony A.
    Los Angeles FLL Region OP
    www.la-fll.org
    https://www.facebook.com/LosAngelesFLL/

    Comment


    • #3
      Re: acceleration problem

      This shows the value of commenting your programs even if you think they are "simple." Here is my version of the program with the comments I THINK are applicable. If the comments differ from what you had in mind then we have discovered the difficulty. I changed the movement block as suggested by LOLComets. capture_20130916_132307.jpg
      Bill Bourn
      Coach, FLL#91 F L eLements
      Mentor, FRC#2170 Titanium Tomahawks

      Comment


      • #4
        Re: acceleration problem

        I don't have an EV3 in front of me to test, but I think I see a couple problems:

        In the version of the loop posted by switch, the Move Block is set to 10 degrees of rotation, then coast. I presume that the intent is to increase the motor power every 10 degrees of motor rotation. This should give a smooth acceleration. But apparently this isn't working correctly. It's not clear why one motor would be running at twice the speed of the other, but this is likely caused by an unexpected interaction of the Move Block's error correcting algorithm with being reset every 10 degrees.

        One other problem is that the loop is set to 100 counts, which would make the motor turn 1000 degrees before the loop exits. But this is probably just a test, so you can fix that.

        The revised version posted by GWhizNonKid has a problem that there is no delay in the loop, so it will set the motor to 25 (init to 15, then add 10 before setting), then immediately set it to 35 and 45 before the motor has even started turning. Perhaps some sort of delay during the acceleration would be helpful.

        Terry
        FLL Mentor/Coach 2006-2015
        Founding Mentor for FRC 1759: 2006-2012
        Founding Mentor for FRC 4999: 2016
        FRC Field Supervisor, Los Angeles 2007-2016
        Manager, Software Development, EMC Corp.

        Comment


        • #5
          Re: acceleration problem

          Now I have run the program on a RileyRover 'bot from Damien Kee. Without a delay in the loop, the speed limit will be reached quicker than you can observe. I put a .1sec wait after the motor block and it makes the acceleration more noticeable, but only after I changed the speed increment in the lower switch leg to 2 instead of 10. In my previous message, I didn't mention that I put a starting value for speed prior to the loop.
          Bill Bourn
          Coach, FLL#91 F L eLements
          Mentor, FRC#2170 Titanium Tomahawks

          Comment


          • #6
            Re: acceleration problem

            Ramping power seems like something you should want to do, but I see teams spend a lot of time and getting very little benefit. Before you hang your hopes on it spend a little time doing some experiments and see if the benefit you predict is the benefit you receive.

            I'd knock of a simple ramp block and run some repeatability tests, comparing the results against not ramping. Attached is a block that ramps power over a specified period of time. You specify the ending power, the ramping time and the number of steps used to bump up the power. Also attached is a test program that uses the block. I don't have my robot here, but it should work.
            Attached Files

            Comment


            • #7
              Re: acceleration problem

              More gold from guru Dean. I did wonder about the "power" variable in use because I remembered the global nature of variables in EV3. I think you mentioned a naming scheme that localizes names by prefixing myblock name to them. Or has the picture merely truncated the name to what we see?

              Answering my own post - "power" is an external global variable that is adjusted by the myblock in the course of its operation.

              Somewhat embarrassed to say that it took too long by 30 seconds or so to see why the loop counter was tied to the switch block. Delay happens for every iteration of the loop except the first. Then I added to the internal commentary on the three blocks to the right of the switch to say power setting increment increases on each iteration of the loop. As I wrote that, I noted that the first power to the motors would already have been incremented by the bump. Seems like an oops to me. How then to have the first iteration at the starting power? I think moving the motor block between the power setting read and its increment will give the performance I expected at the outset. This will require another motor block outside the loop to set the final power at the limit value. I think the final computer power value can be passed out of the loop to it. Off to see if that's true.
              Last edited by GWhizNonKid; 09-16-2013, 10:57 PM.
              Bill Bourn
              Coach, FLL#91 F L eLements
              Mentor, FRC#2170 Titanium Tomahawks

              Comment


              • #8
                Re: acceleration problem

                Thank for the answers. It seem that 10° is a low value, I change lots of parameters but it is still not usable.

                The biggest impact is modifying the "break" at the end. With iteration of 36° and a "break", both motors will end with a small differrence. But if I choose to disable the break to go smoothly, on motors will turn faster than the other.
                My youtube channel

                Comment


                • #9
                  Re: acceleration problem

                  Power is a global. I use it to keep track of the last motor power setting so I always know where to start the ramp. The test program initializes the value to 0 (unnecessary because uninitialized numeric variables are set to zero). The first ramp ramps power from 0 to 75, and the second ramp ramps power from 75 to 0.

                  The comment about travel distance during the ramp is inaccurate, partially because I skip the first wait interval and the ramp ends immediately upon reaching max power, but mostly because I am commanding power and not rate. Duh! Must be a lack of sleep. The trick to ramping up power is for it to complete before you reach your destination. The trick to ramping down power is reaching zero power the same time you reach your destination. That is a far trickier proposition.
                  Last edited by DeanHystad; 09-17-2013, 07:10 AM.

                  Comment


                  • #10
                    Re: acceleration problem

                    Thanks Dan, I will try to make it in this way. I started without variable to be sure that the alrgorythmus is correct but your bloc is very complete.

                    My goal is to have an accelaration bloc and combine that with a line following.
                    My youtube channel

                    Comment


                    • #11
                      Re: acceleration problem

                      Is it correct, zhat you can't do it in this way in NXT-G? Especially the wait block with data input ???

                      Comment


                      • #12
                        Re: acceleration problem

                        You can always create your own Wait MyBlock that has a seconds input plug. Pretty much anything that you can do in EV3 you can also do in NXT-G (except for unsupported sensors).
                        Attached Files
                        Last edited by DeanHystad; 09-18-2013, 08:06 AM.

                        Comment


                        • #13
                          Re: acceleration problem

                          Originally posted by switch View Post
                          Thanks Dan, I will try to make it in this way. I started without variable to be sure that the alrgorythmus is correct but your bloc is very complete.

                          My goal is to have an accelaration bloc and combine that with a line following.
                          No, my block is very incomplete. Ramping for a number of seconds is goofy. OK for testing, but who uses seconds for motor duration? It would be much better if the block ramped over distance, but if you do even sized steps you get an exponential acceleration (slow to ramp when power is low, quick to ramp when the power is high) and there is always the zero power problem (robot doesn't move so waiting for the robot to move never returns). My girls got around this using the acceleration, velocity and displacement equations they learned in science class and a little searching on the internet. Take a look at Torricelli's equation.
                          Last edited by DeanHystad; 09-18-2013, 04:50 AM.

                          Comment


                          • #14
                            Re: acceleration problem

                            We had good luck with simply making a ratio of power to distance travelled. I want to travel 720 degrees. I want to begin at power 20 and end at power 60. So some math blocks can then relate if the motor is at X degrees so far, then it should be using a power of Y.

                            We never had any luck (with our given bot, battery, weight, etc) with any power levels under 20. So if trying to ramp up from 0...test with a higher minimum starting point and see if it helps.

                            Of course if you already varying power to perform proportional line following, the above math gets abit more complex. But take things a step at a time. Do some work on the white board or even Excel to confirm what needs to be calculated.

                            Comment


                            • #15
                              Re: acceleration problem

                              EV3 moves the motors at power setting 1. With NXT my motors started to rotate when power was around 5.

                              To get good linear acceleration you really should create a mapping between motor rotation speed and power setting, and it should be created for your robot. If the power was directly proportional to speed setting power = distance * X should give an exponential response. When ramping up you'll accelerate very slowly at first, but as the robot moves faster the acceleration increases. You get a time linear increase in acceleration, not velocity.

                              My girls went with power = square root(distance) * X. Plotting power against distance you get a line that increases fairly quickly near zero, but flattens out as you move. Plotting power against time you get a straight line.

                              As I said before, don't spend much time on this until you verify that ramping power is actually useful. Many ramping schemes mess up the wheel sync and make the robot drive crooked. Most teams I judge do no power ramping at all. Those that do usually have one step to half power and another to full power. No need for fancy equations and they are happy with the results.

                              Comment

                              Working...
                              X