Week3 : Software




This weeks activities

This week we primarily focused on the software systems side of things . We started by designing a PID loop as shown above. In its most simple terms the PID loop followed this general process:

1. Measuring the error
    -   Compare the current distance of the ball to the target distance of the ball and calculate the                     difference, this is called the error

2. Calculate the P (Proportional) term
    - Multiply the error by the user defined constant KP
    -  This gives a a quick response proportional to how far away the ball is from the target

3. Calculate the I (Integral) term
    - Add up all the past errors over time
    - Multiply the total error by the user defined constant KI
    -This helps correct any small, persistent errors that the P term might have missed, whilst ramping up        over time if the ball is not getting to the setpoint fast enough.

4. Calculate the D (Derivative ) term
    -Compare the current error with the previous error over time to calculate how fast the ball is
        moving from the setpoint     
    - Multiply this rate by the user defined constant KD
    - This help anticipate future errors whilst smoothing out the response

5. Add the P ,I and D terms

6. Repeat process every fixed time period so the system constantly adjusts and reacts to the balls                 movements



Next we designed the method that controls the stepper motor using the output from the PID controller. A stepper motor is driven by a stepper driver and this driver takes low - high - low pulses to drive the stepper by 1 step. The real word movement of "1 step" is defined by the microstepping ability of the stepper driver. In simple terms , if the driver supports microstepping , it will break down one step into smaller steps to achieve smoother movement .  

The speed of a stepper motor is dictated by the time in between subsequent step pulses. A smaller interval results in a faster speed and a longer interval results in a slower speed . The PID system outputs a value analogous to steps per second and so to convert this to a step interval we do ,  StepInterval = 1/(StepsPerSecond. Finally to correctly drive the motor, each state change (LOW-HIGH) or (HIGH-LOW) needs to have a delay of half the step interval.







Because the teensy 4.0 only has one processing core, correct management of this procedure in cpu time is critical or else the procure can cause holdups in the rest of the system. We used the teensy's StepISR interrupt system to pulse the stepper. This Interrupt also allows up to set the priority of the stepper system to a high level so it cant be slowed down by other processes. If we didn't do this, inherently  blocking methods such as sensor polling would increase the step delay seen by the step method, causing the motor to spin at a slower rate than commanded:



We also designed some less important non blocking algorithms such as sensor polling and angle detection using millis() to lower the impact on cpu time. Additionally , we designed two filter libraries (Moving Average Filter and Kalman filter) to filter the noisy data readings from the distance sensor . We are currently testing which filter gives the best performance in terms of speed and reading stability and will remove the lesser performing one soon. The filters are derived from readily available online material shown here:




Finally, we redesigned the distance sensor end beam connector to allow for vertical and angular movement:



Challenges

-       The D term was contributing nothing to the pid output as it was pinned at zero no matter how fast the ball moved. Discovered that this was because we were running the pid loop at 1khz and the tof sensor updates readings at around 50hz. To the pid system, the change / time was effectively zero. I fixed this by only calculating the dterm when a new reading was ready. Pinning the only Dterm to 50hz instead of the entire pid loop was the best solution and there was no obvious slowdown

-   Stepper motor was not running at the speeds commanded, this is because of the slow sensor                    polling slowing down the step pulses so we used the StepISR Interrupt to send the step pulses and        set the process priority



Tasks for next week

- Implement LCD screen and LCD Menu with dynamic PID value control
- Solder everything onto a mainboard and daughterboard for the lcd
- Design enclosures for everything
- Wrap wires
- Clean up


Project Title - 1 Dimension Pid Ball Balancing System
Team Members - Samuel Frimpong /Yuhao Fang
Academic Advisor - Mohammad Hasan


Comments

Popular Posts