Recently, I have been testing the encoders to successfully trigger interrupts on the Arduino board to record the distance the wheels of the platform have traveled. This is so that the platform can travel precise distances using PID algorithms and feedback from the encoders.
While the motors of the platform are not active, the interrupts trigger successfully as the wheels are rotated manually. This is because the encoders produce a clean digital signal to the interrupt pins on their own. However, when any of the motors are active, the inductive noise generated gets carried into the interrupt pins which causes the interrupts to trigger much more often than they are supposed to. This is a problem if we want to get reliable feedback from the encoders.
With the encoder connector carrying the motor noise, one solution was to control the signal from the connector using a pull-up resistor. A pull-up resistor ties the input of the interrupt pin to 5 volts or a HIGH value so that when the encoder signal goes HIGH, it actually translates to 5 volts instead of where the interrupt pin’s threshold voltage may be. Unfortunately, this method was not effective in reducing the false interrupt triggers.
Another solution was to add a 10 microFarad capacitor between ground and the same pin to filter out the inductive noise being carried by the connector. While the capacitive effect on the signal was measured, it also was not effective. This was to be expected because the oscilloscope measurements did not show any noise affecting the signal while the motors were active. Yet the interrupts on the board react as though it is coming from the signal.
Further solutions were to ground the motors directly to the board as well as rearranging the motor and encoder connectors away from each other but to no avail. So while the problem seems to be motor noise travelling through the encoder connector, none of the solutions made a difference which suggests that the problem may be elsewhere.
However, one test showed some results that verified the issue. When connecting only the right motor’s encoder to an interrupt pin with only the left motor active, the same issue in triggering the interrupts occur. Also, the further the left encoder connector is from the right, much less interrupts are triggered. These results definitely indicate motor noise being carried.
Further testing will be done to solve the issue at hand.
The robotic platform will consist of the following components:
Assembling the platform is relatively simple. The first part will be the assembly of the chassis provided by DFRobot. Instructions are provided and easy to follow. One suggestion when assembling the chassis is to install the optical encoders before installing the motors . Instructions are provided on the DFRobot’s website:
Here’s what the chassis looks like when assembled. Next is to wire up the components then upload the code to begin using the platform.
So far, I have enabled the platform to move forward, in reverse, and to turn at an angle using optical encoders. The encoders measure the rotation of the wheels by triggering an interrupt 10 times per revolution. This allows me to calculate the distance that the platform travels and its speed when moving or turning. However, there’s a problem. Based on the measurements taken, the encoder produces much more interrupts than it should resulting in inaccurate calculations. This problem is typically due to contact bouncing which is when a switch or sensor bounces between values several times before settling.
There are two solutions for this problem that were discovered by previous undergraduate students who worked with these encoders. One was a software solutions that incorporated delays in the Arduino code to record an interrupt after the signal from the encoder has settled. I’ve implemented this solution and obtained readings from 1000 interrupts to about 46 interrupts. This is significantly more accurate than initially but still not very accurate. I’ve determined that at maximum speed, the platform’s wheels rotate for 2.3 to 2.5 revolutions every 2 seconds. Thus, the encoders should produce about 23 to 25 interrupts.
The next solution is a hardware solution. It incorporates NAND gates into the circuit in order to minimize the amount of bouncing in the encoders. I’ve also implemented this solution along with the software solution and obtained readings of 26 to 28 interrupts. This is very close to the desired readings but not yet sufficient to increase the precision of the platform. More work needs to be done in order to accurately measure the distance the platform travels which is key for implementing PID algorithms.
My name is Jean Lapaix and I am currently working on improving the precision of a low-cost robotic platform. The platform will be used to demonstrate mathematical concepts to high school students. I plan to utilize optical encoders and PID algorithms to increase the precision of the platform’s mobility as well as use Bluetooth communication to display data for the students to see on a laptop or mobile device.
I began the project in August of 2013 and currently in the prototyping stage of development. I will update this blog of my accomplishments so far and next plans of action to be used as a resource for your prospective projects.