Announcement

Collapse
No announcement yet.

Programming youtube channel

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

  • #46
    (Arc Turn My Block)

    My 4th year team now has a My Block that can drive in arcs and works very similarly to the way Dean describes below, except their ramp up and down logic is just linear. The key is that to be accurate, you do need to synchronize and adjust the wheel speeds continuously based on input from the rotation sensors (using the arc ratios if not going straight). From what I understand of SciQuest's experiment, he is at the mercy of physical variation of motor efficiency (one motor at 75% will go slightly faster than another one). This is why a robot driving straight using two Motor blocks will veer slightly over long distances, and why the Move block uses internal rotation sensor sync feedback. The Move block uses PID, but simple proportional control is plenty adequate.

    For many uses, simply using the Move block to do arc turns in fine, but there are limitations to its accuracy, due to various internal issues. Plus the Move block does not have a ramp up feature, which is very helpful.

    FYI, as to how my team got to this point, it developed over 4 years, mostly as a result of working on line following, which is a very similar feedback loop technique:

    Year 1: Learned how to use a light sensor to find a line, but team decided not to use it and dead-reckoned the whole time.

    Year 2: Learned how to line follow using the simple zig-zag method in the NXT help, then tried 3 state, then 4 state, then eventually used a primitive form of proportional line following, controlling the speed of one wheel based on the light sensor reading.

    Year 3: Improved the proportional line following to control both wheels, then switched to two-sensor line following. Then mid-season I told my son that a "go straight" feedback loop (i.e. Move block substitute) would be almost exactly the same code as two-sensor line following, just using rotation sensors instead of light sensors, and challenged him to write one, which he did. Late in the season, he added a ramp up and ramp down to it.

    Year 4: Modified the "Go Straight" block to apply a given speed reduction ratio to the inside wheel, so now it can drive in arcs and still ramp up and down, all with continuous feedback from the rotation sensors. Some preliminary experiments last year showed that this was still going to be not much better than the Move block, but I told my son that Dean's team had done it and had success with it, so they should give it a try . So far, it is working pretty well, we'll see! In any case, it was very educational to develop.

    Comment


    • #47
      Re: Programming youtube channel

      Ive been trying to get my ARC program working in RobotC first. Im using a PID controller which is set to loop forever.

      (accumulated error is bounded by a 5% decrease each iteration, & the derivative multiplier is actually 0 so this is really a PI controller.)

      Currently error is obtained by taking motorC's rotation sensor (encoder) value, dividing that by two, and subtracting motorB's value. I know thats not the right way of doing things but it seemed like a starting point.

      The PID does its magic based on the error, and the response is applied in one of a few ways. This is how I am using it at the moment:

      Code:
      motor[motorC] = (basePower)/2 - response;
      motor[motorB] = basePower + response;
      But I have also used:

      Code:
      motor[motorC] = (basePower - response)/2;
      motor[motorB] = basePower + response;
      Whats the proper way to calculate the error and apply the response? My way is not smooth, but there is no noticeable drift even after 5+ minutes of running. My crude data logging shows there is some windup (accError is initialized to 0), but I can't see it in the robot's behavior.

      I dont have my measuring tape so I cant be too certain, but as expected it looks like distance(outerWheel, center) is twice distance(innerWheel, center).
      Programming videos for FLL. (I don't like the videos that much and will be replacing them soon-ish)

      Easy data-logging and graphing for NXT-G.

      Comment


      • #48
        Re: Programming youtube channel

        The girls applied correction to only one wheel. Which ever one needed to slow down. Almost all moves were at 100% power, so there was no way to speed up the outside wheel. There control looked like this:

        Code:
        Arc to the Right
        ---------------
        Left Ratio = 1.0
        Right Ratio = (Turn Radius - Track) / Turn Radius
        
        Arc to the Left
        --------------
        Left Ratio = (Turn Radius - Track) / Turn Radius
        Right Ratio = 1.0
        
        Error = (Right / Right Ratio) - (Left / Left Ratio)
        Correction = Error * Proportional Gain
        
        If (Correction < 0)
        ...Left Power = (Base Power + Correction) * Left Ratio
        ...Right Power = Base Power * Right Ratio
        Else
        ...Left Power = Base Power * Left Ratio
        ...Right Power = (Base Power - Correction) * Right Ratio
        End If
        This is from memory, but I think it is pretty close. They spent a lot of time debating running the robot slower and spreading the correction evenly, but speed won.
        Last edited by Dean Hystad; 12-12-2011, 06:59 PM.

        Comment


        • #49
          Re: Programming youtube channel

          I agree with Dean's math below. I think the way to look at it is that you want to do your correction calculations in "full speed" units (not slowed by an arc ratio). Same is true for other speed-related calculations such as ramping up or down. After reading a rotation sensor, immediately convert up to full speed units on both sides, then do your P/PI/PID in full speed units and apply correction, then multiply by the arc ratio just before using it as a final power number.

          However, my team went ahead and applied the correction symmetrically to both wheels in all cases, which is simpler. When at 100% and you can't speed up the outside wheel, I think it just has the effect of a lower gain, so it still works out OK in the end.

          Comment


          • #50
            Re: Programming youtube channel

            Originally posted by Dean Hystad View Post
            The girls computed power continuously throughout the move. They wanted a way to calculate a speed or power that was not dependant on time. They started with a linear ramp based on distance but were unhappy with the result (starts slow then ramps up really fast at the end). Looking at plots they noticed the characteristic shape of x^2, tried using a square root and liked the result. Their equation was (notice not quite Torricelli's equation):

            p1 = sqrt(accel x travel distance) <- Ramp up
            p2 = sqrt(accel x (duration - travel distance)) <- Ramp down
            p3 = max power <- Max power during the middle part

            power = minimum(p1, p2, p3)
            power = maximum(power, 10) <- To prevent stalling
            I really like the simplicity of taking the minimum of 3 power values, but I think there is a better way to calculate the ramping values. In this post I am discussing only how to execute the "ramp up", as ramping down is just a sign change away, and the rest of the problem is elegantly solved by the MAX and MIN functions.

            (I assume that accel is a constant used to tune the rate of acceleration?)

            For example, you start off and remain at a minimum value for some time, before experiencing a large, instantaneous jerk (second derivative of velocity; aka first derivative of acceleration) when p1 exceeds 10, and then experience a decreasing, positive acceleration until p2>p1 and the ramping is done with.


            [excuse my farcical drawings and the lack of labels: x axis is distance_traveled, y axis is velocity]

            That would look like the left part of the first graph, correct? If our goal is to decrease the maximum acceleration then the second graph would seem to be more ideal, but it does have problems with jerk. Note that this approach has constant acceleration, like what Toricelli's equation pertains to. I must admit that I don't quite follow your reference to it.

            If our interest is with minimizing maximum acceleration and jerk (so we can get to max speed in as little of a time as possible), then we should (it would seem to me) use a sigmoidal function for velocity.



            The above graph normalized the Y values of position, acceleration, and jerk to fit in the graph.

            Code:
            p(t) = x^3-x^4/2
            p'(t) = v(t) = 3x^2-2x^3
            p''(t) = a(t) = 6x-6x^2
            p'''(t) = j(t) = 6-12x
            Discontinuities in acceleration result, in a practical sense, with a large jerk, so the formulations above worked to minimize this. The thing is, I have no formal knowledge of kinematics and only the most trivial of physics knowledge: I dont know if jerk (or just the acceleration) actually plays a significant role in the knocking about and loss of precision in robots that come to abrupt starts and starts.

            Ill try asking someone more knowledgeable this evening.

            ::::Please note, that in this post I am talking about the ideal way of doing things. If, or how, to teach this to students is a separate topic/challenge. At the moment, I personally am trying to understand how to do this.
            Programming videos for FLL. (I don't like the videos that much and will be replacing them soon-ish)

            Easy data-logging and graphing for NXT-G.

            Comment


            • #51
              Re: Programming youtube channel

              The ramp equation was incorrect. The entire velocity curve is shifted up to compensate for the motor power deadband instead of using a clipping function. Pulling up the girl's code I see the actually equation is:

              d = min(travel distance, duration - travel distance)
              power = min(sqrt(accel * d) + deadband, max power)

              The Toricelli reference is:

              Toricelli's equation Vf^2 = Vi^2 + 2ad

              For ramping up the initial velocity is zero, so this becomes

              Vf^2 = 2ad or Vf = sqrt(2ad)

              Replace the constant "2a" with "accel" you get:

              Vf = sqrt(accel * d)

              For what they needed I though it was a pretty elegant hack. Remember they solved the acceleration problem first, then found the Toricelli reference.
              Last edited by Dean Hystad; 01-04-2012, 08:41 PM.

              Comment


              • #52
                Re: Programming youtube channel

                Okay I follow the math. I was making a rookie mistake and relying too much on my intuition. It makes sense now!

                I also asked my friend, and he assured me that jerk is only ever used in really weird applications, usually involving elastic bodies. Since I make sure that whatever design the kids make is as brick-like as possible, I don't think that applies here.

                I added power ramping (ramping up only, for the moment) to my P controller / datalogger program how you prescribed and this is what I came up with:



                Its pretty linear, except at the start. Is this because of the motor power being translated upwards by the addition of minimum_power?

                Also, my error is strictly on the interval [-1,1]. I take it that this makes the D controller useless and the I controller unnecessary?
                Programming videos for FLL. (I don't like the videos that much and will be replacing them soon-ish)

                Easy data-logging and graphing for NXT-G.

                Comment


                • #53
                  Re: Programming youtube channel

                  As another method, a half-cycle of a cosine wave (from 0 to pi) makes a pretty good function for smooth transitions, since the slope is zero at both ends. It can be implemented simply as a lookup table. It's a pity that isn't easier to implement in NXT. Quantization errors probably aren't a big deal because the mass of the robot (and the inertia of the drive wheels) would tend to smooth out any jerk effects.
                  FIRST Tech Challenge Judge: 2010, Referee: 2017
                  FIRST LEGO League Mentor, Instructor, and/or Referee/Head Referee since 2011
                  FIRST Robotics Competition judge (Chairman's Award): 2014
                  Dean says I'm an "Oompa Loompa of Science"

                  Comment


                  • #54
                    Re: Programming youtube channel

                    Originally posted by Tom Mosher View Post
                    As another method, a half-cycle of a cosine wave (from 0 to pi) makes a pretty good function for smooth transitions, since the slope is zero at both ends. It can be implemented simply as a lookup table. It's a pity that isn't easier to implement in NXT. Quantization errors probably aren't a big deal because the mass of the robot (and the inertia of the drive wheels) would tend to smooth out any jerk effects.
                    What I am finding out in my testing is that minimizing the acceleration is whats important to reduce knocking. This means the fastest way to get up to speed is constant acceleration, which means linear velocity.

                    Basically, that pretty graph I posted a while ago with all the colors on it was useless exercise (save its educational value).

                    Also, the only sane way I can think of implementing a lookup table involves reading through a text file N many times (where you want the Nth entry)... each time you need to update the value. This would seem to take too long/be pointlessly complicated (though admittedly I am a fan of pointlessly complicated)...
                    Programming videos for FLL. (I don't like the videos that much and will be replacing them soon-ish)

                    Easy data-logging and graphing for NXT-G.

                    Comment


                    • #55
                      Re: Programming youtube channel

                      My blind spot is my love of overly complex solutions

                      Table lookups may be complicated, but they're computationally efficient (all the math is done when you build the table). Would that NXT easily supported arrays and indexing. But I digress...
                      FIRST Tech Challenge Judge: 2010, Referee: 2017
                      FIRST LEGO League Mentor, Instructor, and/or Referee/Head Referee since 2011
                      FIRST Robotics Competition judge (Chairman's Award): 2014
                      Dean says I'm an "Oompa Loompa of Science"

                      Comment


                      • #56
                        Re: Programming youtube channel

                        Originally posted by Tom Mosher View Post
                        My blind spot is my love of overly complex solutions

                        Table lookups may be complicated, but they're computationally efficient (all the math is done when you build the table). Would that NXT easily supported arrays and indexing. But I digress...
                        Taylor series approximation may be a better choice in NXT-G.

                        Comment


                        • #57
                          Re: Programming youtube channel

                          Originally posted by Dean Hystad View Post
                          Taylor series approximation may be a better choice in NXT-G.
                          Right, since lookup tables seem to actually operate in linear time (with regard to the size of the table), not constant, in NXT-G.

                          Taylor series can basically be made to be constant, however.

                          Still too unnecessary for even me to want to do, though.
                          Programming videos for FLL. (I don't like the videos that much and will be replacing them soon-ish)

                          Easy data-logging and graphing for NXT-G.

                          Comment


                          • #58
                            Re: Programming youtube channel

                            Originally posted by SciQuest View Post
                            Right, since lookup tables seem to actually operate in linear time (with regard to the size of the table), not constant, in NXT-G.

                            Taylor series can basically be made to be constant, however.

                            Still too unnecessary for even me to want to do, though.
                            Almost a year later, I've implemented all of the trig functions (including hyperbolic), and their inverses, in NXT-G.

                            In fact, I have used them to create a very snazzy 3 DOF robot arm. It can smoothly move (in work or configuration space) between any series of points in a sphere (in spherical or rectilinear coordinates) that are stored on a file. One of my most advanced classes (not a competition team) in the summer even got to code it (all of it!) themselves: they were earnestly very proud!

                            And just today, I referenced Dean's post before I guided a team through how to make their robot accelerate smoothly. So, thanks, yet again!
                            Programming videos for FLL. (I don't like the videos that much and will be replacing them soon-ish)

                            Easy data-logging and graphing for NXT-G.

                            Comment


                            • #59
                              Re: Programming youtube channel

                              Originally posted by SciQuest View Post
                              Almost a year later, I've implemented all of the trig functions (including hyperbolic), and their inverses, in NXT-G.

                              In fact, I have used them to create a very snazzy 3 DOF robot arm. It can smoothly move (in work or configuration space) between any series of points in a sphere (in spherical or rectilinear coordinates) that are stored on a file. One of my most advanced classes (not a competition team) in the summer even got to code it (all of it!) themselves: they were earnestly very proud!

                              And just today, I referenced Dean's post before I guided a team through how to make their robot accelerate smoothly. So, thanks, yet again!
                              Did you use a Taylor series, and if so, how many terms did you find were sufficient to meet your requirements?
                              FIRST Tech Challenge Judge: 2010, Referee: 2017
                              FIRST LEGO League Mentor, Instructor, and/or Referee/Head Referee since 2011
                              FIRST Robotics Competition judge (Chairman's Award): 2014
                              Dean says I'm an "Oompa Loompa of Science"

                              Comment


                              • #60
                                Re: Programming youtube channel

                                Originally posted by Tom Mosher View Post
                                Did you use a Taylor series, and if so, how many terms did you find were sufficient to meet your requirements?
                                Yes, I did. I created a myblock that could calculate a Taylor series to an arbitrary number of terms.

                                The number of terms varied significantly. 3 or 4 was enough for Sine. Arc-Tangent, however, had huge errors with 7 terms.
                                Programming videos for FLL. (I don't like the videos that much and will be replacing them soon-ish)

                                Easy data-logging and graphing for NXT-G.

                                Comment

                                Working...
                                X