Last post had the Zumo rotate and face a target. I’ve been working on driving towards the target in an attempt to push it off of a table like done in Sumo competitions with great success with the rare occasion that the Zumo thinks it can fly and goes right off the table. While driving towards the target, the program performs light sensor reads and proximity sensor reads as fast as possible while driving. I know that it won’t fall off the table with only the light sensor reads based on a previous post. Therefore, it is hypothesized that the proximity sensor reads are fairly long operations. This post tests that theory out.
The program below uses the Zumo timer, millis()
, to time how long it takes to perform 1000 light sensor reads, and 1000 proximity sensor reads. The time for each read is calculated by simply dividing that amount of time by 1000, and displays on the Serial Monitor.
#include <Zumo32U4.h>
Zumo32U4ProximitySensors proxSensors;
Zumo32U4ButtonA buttonA;
Zumo32U4Motors motors;
Zumo32U4Buzzer buzzer;
Zumo32U4LineSensors lineSensors;
unsigned int lineSensorValues[3];
void setup() {
proxSensors.initThreeSensors();
lineSensors.initThreeSensors();
Serial.begin(115200);
}
void loop() {
unsigned long startTime;
unsigned long runTime;
Serial.println("Light Sensor 1k Test");
startTime=millis();
for(int i=1;i<1000;i++) {
lineSensors.read(lineSensorValues);
}
runTime=millis()-startTime;
Serial.print("Time per Read: ");
Serial.print(runTime/1000.0);
Serial.println(" ms");
Serial.println("Proximity Sensor 1k Test");
startTime=millis();
for(int i=1;i<1000;i++) {
proxSensors.read();
}
runTime=millis()-startTime;
Serial.print("Time per Read: ");
Serial.print(runTime/1000.0);
Serial.println(" ms");
buttonA.waitForButton();
buzzer.playFrequency(440, 200, 15);
}
When I first ran this, I thought that the proximity sensor read section hung up. It took a little over 13 s to run 1k proximity sensor reads!
Here is my output on the Serial Monitor:
Light Sensor 1k Test
Time per Read: 2.53 ms
Proximity Sensor 1k Test
Time per Read: 13.03 ms
I was a little surprised at the light sensor reads as analog reads on an Arduino are in the order of 0.2 ms. However, it is attempting to read three sensor and may perform some averaging. 2.5 ms is not a problem given the speed of the robot. However, 13 ms for a proximity sensor read is way too long. At a motor power of 400, the robot moves at 5000 encoder counts per second for a 75:1 gear ratio. There are 909.7 counts per 360 degree of wheel rotation making the rotational velocity 1980 degrees per second. The wheel and track is 38 mm in diameter. That means for every 360 of rotation, the robot moves almost 120 mm. That puts the robot velocity at 660 mm/s! If it takes 2.53 ms to take a light sensor reading, then the robot could travel 1.7 mm during the measurement. However, if the robot is trying to take both a light sensor array measurement and a proximity sensor measurement, the robot could move an additional 11 mm before the robot could possibly respond to the sensor input. Add in the fact that the robot cannot instantly stop, but needs some time to turn off the motor power and let the momentum of the robot slow down, and you could potentially be off of the table! So…. when charging an object to push it off of the table, we may want to not reading the proximity sensors, or find another way to sensor distance.