Date: November 2012
Location: Oshawa, Ontario
Company: UOIT
Team: Cameron, Calvin, Jimmy

Objective:

Using the provided cart, use the motor’s encoder and the track’s IR limit switches to control the cart in 3 different ways:

1. Move the cart from end to end 4 times
2. Same as 1 but stopping exactly in the middle when completed
3. Same as 2 but maintaining constant speed throughout.

Solution:

This lab was obviously designed to gradually introduce us to real-world control systems. There were 2 issues that really hit us hard and early though:

1. None of us had been taught control systems
2. None of us had knowledge of Code Warrior, the IDE used in the labs.

Nevertheless, we divided and conquered. We knew we’d have to generate C++ code to program the Freescale HSC12 board, so I began writing some code to handle the encoder and the limit switches. Jimmy and Calvin began digging through documentation trying to get the project setup in Code Warrior. When we met up, I realized I had written Arduino-ready code, but it wasn’t going to mesh well with the HCS12 structure. Some quick fixes had us up and rolling in no time. Task 1 was accomplished shortly after compiling the first test program.

Task 2 was straightforward as well. While task 1 was being graded, I was writing code to listen to the encoder during each “lap” of the track. I averaged out all the runs, and stopped the cart in the middle using the estimated distance calculated. We cut power to the motors exactly in the middle each time, but the momentum of the cart pushed it past the middle each time. More on that later.

Task 3 was the real deal. Speed control is a huge part of control systems and this was  a gentle introduction. We used the internal clock to calculate the time it took for the encoders to tick a specific number of times, and based our speed off this. Super ugly, extremely inaccurate. At the time we didn’t understand how to implement timers or what PID meant, so it just got worse.

With our inaccurate speed measurements, we bumped the speed up/down in static intervals every n-ticks of the encoders until the speed was where we wanted it. This meant our correction frequency changed based on speed! In hindsight, we should have looked into control theory for motors, but we were in a roll and didn’t want to break out momentum. Another rookie mistake. Below is the final video of our graded attempt.

Had we researched control theory a bit more, we would have realized that a PID controller would have easily taken care of the speed and position control. It would have accounted for the overshoot of the cart when it tried stopping in the middle. It would have forced us to use a timer to get consistent motor speed samples. It would have made the code base easier to adjust, needing at most 6 variables (PID for each controller). Having the knowledge I have now, this could have been a breeze.