A better solution needed to be found. Using the same type of optical targets and sensors, a more robust and flexible solution was devised using a single PIC16F690 in place of the PCB described above, which included seven ICs. The PIC allowed the researcher to use common I2C bus communications and added unparalleled flexibility through implementation of a software solution. With a software-based PIC solution, the tachometer can easily be modified to operate on other robots with two, three, or four odometry sensors. Further, the actual sensor is immaterial; the PIC can be adapted to work with any regularly occurring digital signal such as one from a Hall Effect sensor. The PIC sensor could be used to provide feedback about any motor shaft motion, such as motors used to position a robotic arm. This adaptability was a design goal throughout the development. Solutions should be flexible enough to allow for their implementation on follow-on SMART program robots.
Whereas the earlier device used hardware to measure displacement, an angular velocity measurement technique was selected for the Creature to smooth out the observed data. The microcontroller’s fundamental task is to count the number of cycles reported by each sensor in a fixed period. The PIC16F690 used for wheel speed measurement accepts three inputs, one from each Hamamatsu optical sensor observing the Creature’s three motor output shafts. The sensors provide a digital signal that goes to a high logic state when the black portion of the binary encoder wheel passes through its FOV. The PIC’s program counts the number of transitions, i.e. changes from high to low or low to high logic states, in a fixed period of time. If one assumes that one cycle includes two transitions, dividing the count of the transitions by two times the period gives the frequency in cycles per second of the motor shaft. A 250 ms period was chosen as the sampling period. A longer period would have smoothed the frequency data more and mitigated the observed optical sensor errors due to occasional failures to detect some target sectors. Additionally, detecting low frequency signals (10 to 17 Hz) associated with very slow wheel speeds required a longer sampling time. Longer periods, though, obscured short-term variations in motor frequency, for example during accelerations. Ultimately, a 250 ms period was chosen as a compromise. Further, it allowed for a one- byte data value at the maximum expected signal frequency of 220 to 250 Hz, and simplified the assembly language mathematics, since multiplication by two consists of a simple bit shift.
In addition to measuring the motor shaft frequencies, the PIC must also store the data and communicate it to the robot’s CPU, the BL2600. It was decided to use I2C bus communications for this application because the CPU’s serial ports were committed to sonar and IMU data communications. Rudimentary communications protocols outside the mainstream have been used on some earlier odometry sensors, but such protocols violated the design goal that devices built for the Creature be adaptable to a wider range of vehicles. Using the I2C bus protocol allowed the CPU, serving as bus master, to poll slave devices at its convenience. By using the I2C protocol the data was available to the CPU with minimal delay. I2C uses a simple bi-directional, two-wire hardware layer that
function library. Previous SMART robots, such as Herkamp’s Bigfoot, have utilized I2C communications, but the bi-directional nature of the signals coupled with I/O limitations of the BL2000 forced the researcher to divide the SCL and SDA lines into an input and an output pin for each signal [11]. The BL2600 installed on the Creature was configured to use sinking current outputs, and achieves true bi-directional serial communications through two pins.
C. PROGRAM FLOW
Figures 34, 35, and 36 show flow charts of the wheel tachometer assembly language program. The main program element is a loop during which the PIC monitors three digital inputs. If a transition, a change in the digital input from a low to high logic state or high to low logic state, is detected, then the register associated with that motor shaft count is incremented. A short 40 µs delay is implemented after the three signals are tested for a transition in their logic states to allow for rise time in the digital signal lines. The PIC’s TIMER1 counter is seeded with a literal value prior to executing the loop. During code execution, the TIMER1 counter increments automatically from the seed value until the counter overflows, which occurs after 250 ms have elapsed. The overflow sets an interrupt flag.
The remainder of the program, shown in Figure 36, is an interrupt service routine (ISR) handler. Because the researcher lacked extensive assembly language programming experience, example code to handle the ISR tasks and I2C communications was found [38]. The example was modified to measure the wheel frequencies. The code monitors for ISR triggered by the overflow of the counter, which signals the completion of the 250 ms timing. If the ISR was caused by the counter overflow, the counter’s overflow flag is reset along with the seed value for the counter for the next 250 ms period. To produce an output value in cycles per second from the number of transitions in 0.25 s, and assuming one cycle per two transitions, the code multiplies the number of transitions by two. The three values representing the frequency in cycles per second for the wheel rotational speed are saved to separate registers so as to be available when requested by the I2C bus master.
Figure 35. Tachometer Program Flowchart Page 2.