I'm using the Arduino Uno and 100:1 microgear DC motors with magnetic encoders from Pololu.com. I'm trying to figure out how many "steps" correlate to one revolution of my 60x8mm wheels. The readings that are printing out are not consistent with my original step prediction. I guessed that the step count would be around 600 steps per wheel revolution since we are counting rising edges using an interrupt. The code that follows is kind of sloppy, please bare with me. I did not include all of the functions since they do not affect what's going on here.
#include <NewPing.h>
#define echoPin 4
#define trigPin 7
#define IRsensor_L A0
#define IRsensor_R A1
/***PINS***/
volatile unsigned char step_pin=2; //encoder
const unsigned char motor1Forward=3; //1A motor LEFT positive logic pin
const unsigned char motor1Reverse=5; //2A motor LEFT negative logic pin
const unsigned char motor2Reverse=10; //1B motor RIGHT positive logic pin
const unsigned char motor2Forward=11; //2B motor RIGHT negative logic pin
/***VARIABLES***/
byte logic=0;
volatile long stepCount=0;
const unsigned char power1 = 20;
const unsigned char power2 = 100;
const unsigned char power3 = 175;
const unsigned char powerMAX = 250;
unsigned int distSonor; //Sonor
unsigned int distIR_L; //IR
unsigned int distIR_R; //IR
float x; //test raw Sonor data
NewPing sonar(trigPin,echoPin,200); //sets up the sonar
void setup() {
Serial.begin(9600);
pinMode(step_pin,INPUT);
pinMode(motor1Forward, OUTPUT);
pinMode(motor1Reverse, OUTPUT);
pinMode(motor2Forward, OUTPUT);
pinMode(motor2Reverse, OUTPUT);
pinMode(IRsensor_L, INPUT);
pinMode(IRsensor_R, INPUT);
attachInterrupt(digitalPinToInterrupt(2), count, RISING);
delay(3000);
}
/***MAIN***/
void loop() {
interrupts();
drive();
while (stepCount >= 300){
halt();
Serial.println(stepCount);
stepCount = 0;
Serial.println(stepCount);
}
delay(2000);
/*
x=sonar.ping_cm();
distIR_L= irVal_L();
distIR_R = irVal_R();
Serial.print("IR LEFT Sensor value = ");
Serial.println(distIR_L);
Serial.print("IR RIGHT Sensor value = ");
Serial.println(distIR_R);
*/
//x=sonar.ping_cm();
//Serial.print("Sonar value = ");
//Serial.println(x);
//Serial.print("LOGIC is ");
//Serial.println(logic);
//digitalWrite(step_pin, LOW);
}
void count(){ //ISR
logic=digitalRead(step_pin);
if(logic==1){
stepCount++;
noInterrupts();
}
You have not told us how many pulses per revolution come from the encoder or where the encoder is attached - is it attached to the motor shaft or to the shaft the wheel is attached to.
okay, so here is the full code. the motors we are using is DC motor 100:1 gears with a dual shaft that each holds an magnetic encoder that has a CPR of 12. Sorry for the misinformation.
First time on a forum asking for help so if you can help me out, I will appreciate it very much.
PacRat16:
okay, so here is the full code. the motors we are using is DC motor 100:1 gears with a dual shaft that each holds an magnetic encoder that has a CPR of 12.
I'm trying to figure out how many "steps" correlate to one revolution of my 60x8mm wheels.
Now that we have the data the answer is either 12 or 1200 depending on whether the encoder is after or before the gearbox.
These encode motor shaft revolutions, so for the full quadrature case, with a 100:1 gearbox, it would be 1200 counts per gearbox output shaft revolution.
However, the OP appears to be counting a single rising transition on one channel only, for 300 counts per gearbox output shaft revolution, and even then for only one rotation direction.
These encode motor shaft revolutions, so for the full quadrature case, with a 100:1 gearbox, it would be 1200 counts per gearbox output shaft revolution.
However, the OP appears to be counting a single rising transition on one channel only, for 300 counts per gearbox output shaft revolution, and even then for only one rotation direction.
yes i only have one channel from the encoder that i am reading from. Is it necessary to have both channel connected? I'm assuming connecting the other channel from the encoder helps counts the opposite direction?
My main problem is controlling the step counts. For example: Making it stop at exactly 300 steps.
I'm assuming connecting the other channel from the encoder helps counts the opposite direction?
Your code is wrong. It counts pulses in one direction only. Google for several examples of correct Arduino quadrature encoder code.
It is difficult to have the motor stop at, for example, exactly 300 counts, even if your code were correct and capable of counting backwards. You have to implement a PID position loop to do that.
jremington:
You have to implement a PID position loop to do that.
This is a question for my own edification ...
Does a PID system require the position to oscillate a little around the chosen positon - for example between 295 and 305?
Does a PID system require the position to oscillate a little around the chosen positon - for example between 295 and 305?
In general not if properly tuned, in which case there might be a small overshoot.
However since the position measuring system is discrete in this case (with no fractional steps) it may be quite difficult to tune it to settle exactly on 300 without oscillation of +/- 1 or more.
well the purpose of this robot car im making is for the micromouse competition. We need a step counter to memorize the maze so when we run the car the second round, it would sue the pre-recorded steps to nagvigate through the maze to the destination.
If anyone have a better suggestion then this strategy, i wouldn't mind hearing it.
Wheels slip. They always slip. Even on solid surfaces, they slip. Slip is what generates traction. Without traction, you don't move.
Depending on the accuracy you require, this slip may be insignificant. But if it is significant then you need a more direct way of measuring distance. The sensors inside optical computer mice (is there any other kind except optical these days?) can be interfaced to an Arduino reasonably easy. The mouse sensor watches the ground move under the robot.
Wheels slip. They always slip. Even on solid surfaces, they slip. Slip is what generates traction.
What you really think?
Slipping is what loses traction, friction is what generates traction. Wheels do not always slip.
High grip tyres are often soft, which leads to motion loss through distortion of the tyre, rather
than via slip. The truism is that odometry can never be completely precise (but it can be very
accurate on the right surface with the right wheels, otherwise turtle graphics robots would not
work).
In icy/wet/leaf-strewn conditions sand is used on railway lines to increase grip (prevent
slip by increasing friction) and thus allow traction.
Tight turning circles can lead to slip on the edges of the tyre, with or without slip in the
centre, which means very narrow tyres/wheels are often a feature of high performing odometry.
