Announcement

Collapse
No announcement yet.

PID progaming help

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

  • PID progaming help

    I have been trying to create a PID loop and haven't been able to figure them out. Does anyone have advice?

  • #2
    To do PID control, you need a feedback loop. Are you doing your own PID control or are you using the Modern Robotics built-in PID?
    If you are doing your own PID control, you will have some sort of feedback loop where you compare your current position to your target position and figure out how much power you need to drive the motor. The pseudo-code looks something like this:
    Code:
    double error = target;
    double totalError = 0;
    double prevTime = getCurrentTime();
    while (abs(error) > tolerance)    //not reaching target yet
    {
        double currTime = getCurrentTime();
        double deltaTime = currTime - prevTime;
        prevTime = currTime;
        double currPosition = getPosition();
        error = target - currPosition;
        totalError += error*deltaTime;
        double pTerm = Kp*error;    // This term is proportional to the error
        double iTerm = Ki*totalError;   // This term is integrating the error over time
        double dTerm = Kd*(error/deltaTime);  // This term is the derivative of error over time
        double motorPower = pTerm + iTerm + dTerm;
        setMotorPower(clip(motorPower));
    }

    Comment


    • #3
      I would like to use "dead" omni wheels with encoders to provide position feed back (like some FRC teams), and use the "RUN_WITHOUT_ENCODERS" mode on the motors.

      Comment


      • #4
        RUN_WITHOUT_ENCODERS means you are doing your own PID control. You can still use the encoders on the NeveRest motors even if you are running in RUN_WITHOUT_ENCODERS mode. Is there a reason why you want to use idler Omni wheels? One reason would be because your drive train is doing strafing. Even so, there is a way to use the four encoders on the wheels to determine the X distance on a mecanum drive train. Our library does that.

        Comment


        • #5
          I was thinking a bought using idler encoder wheels to reduce wheel slip and maybe use a "run to target" method with a controller.

          Here is the algorithm:
          1. check the current position
          2. get target from gamepad
            1. gamepad value * 10
          3. set encoder target to gamepad target
          4. run to target
          5. update target

          Hope this makes sense.

          Comment


          • #6
            Are you doing PID controlled drive in TeleOp? What are you trying to achieve?

            Comment


            • #7
              Are you doing PID controlled drive in TeleOp?
              Yep

              What are you trying to achieve?
              More control and to see if it works.

              Comment


              • #8
                Well, I am trying to understand what kind of benefit you will achieve with PID control. The way you described it doesn't make sense to me. I assume your step 5 is really "loop back to step 1". If that's the case, it means your target is changing in every loop (i.e. a moving target). That defeats the purpose of PID control where you are supposed to go towards the target smoothly in a period of time. If the target is changing in every loop, there is no time for PID control to react to it.
                Having said that, there are benefits of doing PID control in teleop drive but you need to figure out what aspect PID control can help. For example, one thing PID control can help is to keep the robot driving straight. Sometimes robots may have a drive train that is not very symmetrical either because one side is heavier than the other or one side has more friction than the other. In that case, even you push the stick forward straight, the robot will curve either to the left or to the right. Now I always recommend to try fixing the drive train first before going for a software solution. But in case, there is a limitation in the design, software could help. In this case, you can use PID control in conjunction with a gyro to keep the robot running straight. That goal makes a lot more sense to use PID control.

                Comment


                • #9
                  Thinking about it some more for your scenario, the only way it makes sense is for PID control to control velocity, not position. So the stick position is really indicating the speed the robot should run. By doing speed control, each wheel of the robot will try to run at the same speed thus achieving the same result as using the gyro to keep the robot running straight. But in any case, you don't need a tracking wheel. The only reason to use a tracking wheel is to do mecanum driving where strafing may cause some wheels to slip and thus compromising the accuracy of the measurement.

                  Comment


                  • #10
                    One of the resigns why I wonted to know how to make PID loops is because I would like to start working with Raspberry PI and Ardunio. Another is, I would like to create an ante-slip system for the drive train and hopefully have as much pushing power as possible.

                    Comment


                    • #11
                      You don't need Raspberry Pi or Arduino to use tracking wheels. You can just connect an encoder to two digital input channels and WPILib even have an Encoder class to support it.

                      Comment


                      • #12
                        Not with FTC but open source and away from competition.

                        Comment


                        • #13
                          Hi Inventer B,

                          I do share your interest in robotics within FTC and outside of it. I am in process of updating my blog posts about these items, such as speed and position measurements with encoders, speed and position control with PID, interrelated controls, and local interlocks. I started to do multi-motor (2, 4, or 6) controls using Arduino IDE, but then realized it was simpler and cheaper to do the 6 motor control with STM32F407 without using Arduino IDE.

                          During these developments, I have learned that the position measurement with quadrature encoders is trivial, but the accurate speed measurement is surprisingly complicated with slow speeds, inaccurate sensor positions, and inaccurate magnet positions. If the configuration data for number of magnets is wrong, the speed readings are terrible.

                          With the 2 and 4 motor controls, I am using Teensy 3.2/3.5 controllers that don't support hardware floating point. For them, I didn't find a high quality integer PID library and I had to create my own - it was "fun" because the range limits are really hurting you. The STM32F407 has hardware floating point which allows simpler PID.

                          Some examples of interrelated controls are turning control and mecanum wheel drive. In turning control 1, 2, or 3 pairs of motors are controlled in a way where the slower and faster side are in forced synchronization. This can be combined with the drive to target position. In mecanum wheel drive, the user command is for forward speed, turning, and strafing speed. The cascade level control with an IMU sensor is in the higher level unit, such as Android phone or Raspberry Pi.

                          An example of local interlock is a set of limit switches in the robot connected directly to speed controller to stop the robot movement in the offending direction.

                          Good luck with your experimentations.

                          Comment


                          • #14
                            Originally posted by Ollie View Post
                            Hi Inventer B,

                            I do share your interest in robotics within FTC and outside of it. I am in process of updating my blog posts about these items, such as speed and position measurements with encoders, speed and position control with PID, interrelated controls, and local interlocks. I started to do multi-motor (2, 4, or 6) controls using Arduino IDE, but then realized it was simpler and cheaper to do the 6 motor control with STM32F407 without using Arduino IDE.

                            During these developments, I have learned that the position measurement with quadrature encoders is trivial, but the accurate speed measurement is surprisingly complicated with slow speeds, inaccurate sensor positions, and inaccurate magnet positions. If the configuration data for number of magnets is wrong, the speed readings are terrible.

                            With the 2 and 4 motor controls, I am using Teensy 3.2/3.5 controllers that don't support hardware floating point. For them, I didn't find a high quality integer PID library and I had to create my own - it was "fun" because the range limits are really hurting you. The STM32F407 has hardware floating point which allows simpler PID.

                            Some examples of interrelated controls are turning control and mecanum wheel drive. In turning control 1, 2, or 3 pairs of motors are controlled in a way where the slower and faster side are in forced synchronization. This can be combined with the drive to target position. In mecanum wheel drive, the user command is for forward speed, turning, and strafing speed. The cascade level control with an IMU sensor is in the higher level unit, such as Android phone or Raspberry Pi.

                            An example of local interlock is a set of limit switches in the robot connected directly to speed controller to stop the robot movement in the offending direction.

                            Good luck with your experimentations.
                            Glad to find someone that is playing with open source robotics to...

                            Comment

                            Working...
                            X