Notifications
Clear all

Thoughts on motor encoders

Page 3 / 3

huckOhio
(@huckohio)
Estimable Member
Joined: 2 years ago
Posts: 175
 

@robotbuilder 

Thank you.  I opened up the Dead Reckoning article listed at the bottom of the page, took one look at the math equations and ran away.  It's been too long since I had a math class.


ReplyQuote
robotBuilder
(@robotbuilder)
Prominent Member
Joined: 2 years ago
Posts: 948
 

@huckohio 

But Dafydd Walters' code is simple enough in listing 3.

I used it to write code for a robot simulation.  I have yet to implement it in a robot base.

Imagine you are inside the robot and thus,  like the robot's software,  cut off from any sensory input except the encoder data.  You don't know where you are or what direction you are pointing.  So you set your position to 0,0 and direction to 0 degrees.  Now you can power up your motors and observe how much they have moved using the encoder data.  So in theory you can at any time say where you are relative to your start position and in what direction you are now moving relative to your starting direction. If you had a LCD display you could use it to show the x,y,theta of the robot as it moved around.  You could then drive it by remote control yourself to test how accurately its position could be determined from the encoder data.  This is all dead reckoning by odometry is.  Of course over time errors will build up which is why the robot ultimately needs to be able to reference its position using sensors (like sonar) to reset its actual position and direction.

Another way is with stepper motors that don't need encoders.  You can accurately turn them by a known amount with a known number of pulses. There are examples online including video of them drawing on paper.

https://www.pcbway.com/project/shareproject/Drawing_Turtle_Robot___version_Arduino_Nano.html

 


ReplyQuote
THRandell
(@thrandell)
Eminent Member
Joined: 5 months ago
Posts: 45
 

@dale

Dale,

Please don't spend any more time on my XOR gate question.  I'm getting 1,250 clicks per revolution of the wheel and that seems pretty good to me.  I'm an Arduino user so I think that I'll just continue to refine what I've got with things like:

 

 

int16_t getCountsAndResetLeft() {
  
  cli();
  int16_t counts = leftClicks;
  leftClicks = 0;
  sei();
  return counts;
}

 

 

I did come across an Arduino C++ library that claims to speed up calls like digitalRead and digitalWrite.  So I'll probably explore that as time permits.  Thanks for your help.

 

Tom


ReplyQuote
NewburyPi
(@dale)
Estimable Member
Joined: 2 years ago
Posts: 120
Topic starter  

@thrandell 

Please don't spend any more time on my XOR gate question.  

Too late 🙂 My interest is piqued now. Besides, I came across a major error in my code while I was drifting off Tuesday night. Also @robotBuilder 's method of determining displacement and heading looks very useful. I'll need to massauge it a bit, vor my application, but it should help when I get deeper into SLAM. 

 

PS: Good luck with your robot. 

 

This post was modified 2 weeks ago by NewburyPi

--
Dale


ReplyQuote
THRandell
(@thrandell)
Eminent Member
Joined: 5 months ago
Posts: 45
 

@dale

PS: Good luck with your robot. 

Thanks I'll need it!

How's your work on ARDVARC coming along?  Do you have any photos that you can post?

Tom


ReplyQuote
frogandtoad
(@frogandtoad)
Prominent Member
Joined: 2 years ago
Posts: 828
 
Posted by: @robotbuilder

@huckohio 

But Dafydd Walters' code is simple enough in listing 3.

I used it to write code for a robot simulation.  I have yet to implement it in a robot base.

Imagine you are inside the robot and thus,  like the robot's software,  cut off from any sensory input except the encoder data.  You don't know where you are or what direction you are pointing.  So you set your position to 0,0 and direction to 0 degrees.  Now you can power up your motors and observe how much they have moved using the encoder data.  So in theory you can at any time say where you are relative to your start position and in what direction you are now moving relative to your starting direction. If you had a LCD display you could use it to show the x,y,theta of the robot as it moved around.  You could then drive it by remote control yourself to test how accurately its position could be determined from the encoder data.  This is all dead reckoning by odometry is.  Of course over time errors will build up which is why the robot ultimately needs to be able to reference its position using sensors (like sonar) to reset its actual position and direction.

Another way is with stepper motors that don't need encoders.  You can accurately turn them by a known amount with a known number of pulses. There are examples online including video of them drawing on paper.

https://www.pcbway.com/project/shareproject/Drawing_Turtle_Robot___version_Arduino_Nano.html

 

A compass or full on IMU can greatly enhance such awareness, but even then it's probably still not the ants pants of it all.  I think vision is the key, but even then I think it must be backed up by some exceptional and creative algorithms.

Cheers.


NewburyPi liked
ReplyQuote
Page 3 / 3