Open Discussion encoder direction and dedicated pics

Community General Discussions
1

I am on to mapping with Walter now. He has stripes on his wheels and a typical IR led/sensor set-up for each wheel. There are actually 2 sets of encoders --One set R/L for the navigation and a second that are attached to a dedicated 28x2 whose sole purpose is to watch the wheels go by (he has a couple eeproms attached as well).

Now, I know a typical encoder either rotary or optical works off of the 1/2-step-off idea so "one 1/2" of each encoder will be triggered first thus showing the direction of travel. Considering that picaxes are slow as dirt and that there would be a total of 4 things to watch (which one changed first on which of two sides?) I simply don't think that the picaxe is going to keep up. Not to mention adding to the loop time is a big chunk devoted to writing the "counts" to the eeprom. (I am quite surprised at how slowly you need to write to these eeprom chips... I need at least 5us of pause between writes to keep writing clean data)

As I entered this problem I assumed hey, this is no problem, I will simply tell the encoder picaxe which way we intend to go, and it would count which ever wheel is needed and stop counting and write when we tell it the direction has changed. (BTW --an assumption is made here that the wheels are going the same speed and during fwd and spins only one encoder is watched). This method has been a massive failure of serial sends, interrupt loops (that are constantly being interrupted) and a lot of too-fast writes and spoiled data coming out of the eeprom when I read back the data. --The writing to the eeprom is done inside of the interrupt loop and with serial input being done in the background, a new byte can come in and sit right on top of the byte I am trying to write and spoil the whole lot up. So here we are...

Simple problem: I gotta chip that does nothing but watch wheels and it simply needs to know when the direction of the wheels has changed. Right now, I am soldering a simple board of transistors that I will attach directly to 12v power going to the motors. The transistors are there of course to keep the 5v side and the 12v side from fighting and to keep the magic smoke in my little robot brains. --I would attach directly to the PWM signal coming out of the navigation chip itself, but at low PWM's I don't know if it will be enough juice to click a transistor or input pin high. I don't wanna hear about adc's either, this has to be digital for a quick, yes-or-no read of the pins. This way, the pic simply has to check 4 pins or 1/2 a byte to see which way the motors are going and if that direction has changed, start count/stop count/write direction to eeprom and/or write count to eeprom. This is by no way a suggestion of the way it is supposed to be done, but I am tired and have been working on this for quite some time and when in doubt, I usally find a hardware solution before a code-based one.

I guess that's it. As I said, this is an open discussion, gimme what you got.

P.s. --the data going to the eeprom is in 2-byte packages: the first byte is a letter noting the wheel and/or direction and the second is the number of counts.

I.e.

R,127 --this is right spin 127 counts

r,47 --this is right slide, 47 counts

f,35 --forward 35

L, 34 --left spin 34

l,45  --left slide 45

E,0 --end of mapping

etc. etc. etc.

2

Per a 5 minute talk with rik…

It seems that the “watch 4 input pins to tell direction” thing may or may not be the way to go. This really all comes down to processing speed and how many things need to be watched at once. As I think more about this, using regular quad-encoders might be just as much thinking as watching 4 pins and 2 simple single encoders. Maybe I am just a little turned off by proper encoders as I have not written any test code for them --or even thought about how that code would be assembled… I dunno.

As always, test board and test encoders will probably tell the tale. Still want to hear thoughts, though.

3

watching four pins

Four binary pins code for up to 16 different states. I did the dry-erase-marker-on-the-window-math and figured out that 8 of them code for the “slides”, 4 code for “stand”, 2 code for spin and the remaining 2 for drive.

That’s one if/then in your code or every bit of data. Which makes sense. Or a sixteen-way case/select.

Don’t you use that kick-ass motor driver with the reversing relays? One bit per wheel. Who cares about “stand” anyway? That’s the same as “forward zero”. Hot wire your relay coil driving voltage into the encoder picaxe. Forget about “stand”. Two input bits, four permutations: Forward, Reverse, Spin Right, Spin Left.

Just forget the slides for now. (When one wheels blocks and the other turns.)

4

Storing two sentences per move

How about we store moves per wheel?

S,20  – starboard wheel forward 20 counts
s,25  – starboard wheel reverse 25 counts
P, 240 – portside …
p, 12  – p…

Double the data storage requirement. Do all the clever stuf in Processing.org. Even “semi slides” aka wide turns become available.

5

I forgot about the relays…

I have 2 simple lines going high for reverse. --That cuts that 16 down a bit (not a bit but a little… HA!)

So I went to the beach and watch the kids swim a bit --did some thinkin’. Seems like we got 4 choices or 6 depending on how you look at it. We have on or off R,  on or off L, Rev L and Rev R. Actually, if a motor is reversed, it is on. Actually, actually, if one motor is reversed it is a given that it is A) on and B) that we are doing a spin. So let me think…

(2) If Reversed then its spin R or L

(2) If on  L --or-- R

(1) If on  L  --and-- R

I guess that’s 5 with the slides. I would have to think that this wee little picaxe should be able to keep up with that…

6

Just a sum total of each wheel

I thought about that but it is twice the writes to the eeprom but more importantly, I think in the end the math will end up in a “as the crow flies” instead of a path with “waypoints” (places we changed directions along the way) that we could potentially follow back to our start position.

7

You lost me at "hello"

I hope that that made sense to you, at least. You lost me. I suppose this is where the pinout diagram with truth table comes in.

8

That’s weird… I found you at goodbye…

Sir, I am soldering as we speak. I will have numbers for you soon.

9

Man, I have no idea what are

Man, I have no idea what are you talking about here… How is your system working? I guess I should look up your robot page and figure it out…

Do you have a Picaxe that controls the motors? Can that same chip read the encoders (one channel per side) count them up until a change direction is issued and then store that in the eeprom (or send back to the main controller)? Any change in direction should stop the motors first, that is the point when you transfer the encoder count to another variable and reset the count variable to be able to count the new travel.

You actually don’t need 2 channels per side if you’re not using PID to home in to an exact distance or turn angle. One channel per side is enough, count one side (and use that count for the final result) and substract the other side to get the error that you feed to a PID control to adjust the motors to drive in a straight line or make an on the spot turn. You can also adjust that control to drive curves.

Take a look at my MotorController code for MiniEric robot (in Arduino). I do not store any counted move, I just make sure the robot travels a specified distance or turn. At the end of the travel, the MotorController reports Done so the next travel command is issued. The main controller has to keep up adding the total traveled distance.

Hope this helps…

10

2 picaxes

Hey rob-x --the issue is processing speed really. The main navigation brain cannot watch sonar at the same time it is counting encoders. I have a second chip dedicated to just watching the encoders but it needs to be able to know which direction the wheels are going and when they change. I could use quad-encoders but even then we have a processing power issue. Instead we have the situation we are discussing above. By the way…

(rik) --It seems the transistors to input pins is a go. I finished the board and got everything wired last night. There are a total of 6 options, but with the let b6=pins command, we get one of 6 byte values that can be easily be written to the eeprom. Any and all direction changes (and thus a write and start counting again) come down to just a simple --if current direction_byte != old_direction_byte, then start new count.

Now they I see this system working, and see the code required to watch even just one quad-encoder, I have to say this is a far superior system, even if it does requires extra hardware. I now have to write some test code to check my math here and tidy up the processing code to start/stop and dump the map but I left a lot of placeholders when I built the control panel so it should just be a lot of cutting a pasting.

I think we might be getting somewhere.

11

To 255 and beyond!

Not sure if this coding problem has come up yet. Your counters are bytes and will overflow very easily. Only four revolutions of a wheel will do the trick. Any strategies for that yet?

12

Chris, I believe it’s time

Chris, I believe it’s time for you to move on to Arduino! There a a few users here on LMR that can help you if you get stuck (me included) and you get more speed and possibilities. You won’t regret it! 

13

How others do it.

FYI: my Parallax position controllers us a PIC for each encoder but you could probably use just one. Each encoder wheel has 2 sets of IR LED’s and IR Sensors spaced apart so that one set triggers slightly before the other one and that tells the PIC which direction that wheel is moving.

14

It’s done, it works, it is very inaccurate…

Well, it is up and running. I have 4 wires coming into my mapping chip: Motor A, Reverse A, Motor B and Reverse B. These 4 pins are converted to one of (7) options (let b1=pinsB) which equate to  Forward, Reverse, Spin Right, Spin Left, Slide Right, Slide Left and Off. The loop is pretty simple, keep counting until b1 (the input pins) have changed. When that happens, we go to a subroutine to write 2 variables to the EEPROM, move number and count.

When read back, the first variable is read and put into a select case. From here the direction (fwd, spin, etc) is converted to a letter value. This letter value and the following “how far” number are then sent via bluetooth to the computer. Within processing, the qualifier (the letter) sets the math equation to use to convert encoder counts to degrees and distance traveled forward. And then of course, we end up at rik’s map, or actually now nuumio’s enhanced map and bam, we got a scale drawing of where we have gone.

Now, the system is solid. Everything works, all data is clean and is coming out the same as it went in. I have even printed the list of “moves” and compared it to a video tape of walter doing that “run”. Everything is working great. Except it really isn’t.

The fatal flaw I quickly found is that every turn is built on the previous turns. At each turn, you are not re-establishing your angle from  a given point, you are figuring out how far you are turning from how far you think you turned last time. Maybe 5 or 10 moves are pretty close to what it actually did, while adding inaccuracy each move past that. You also have to remember that the robot is still moving during the write cycle of the code, assuming about 90us to write data to the eeprom, well, a lot can change in a 1/10 of a second. Think of this: If just one count is lost during a write cycle when walter is turning, you loose %3 – 1/4 turn = 32 counts, 1 is %3 of 32. Three turns later and now you are off almost %10.

I am wicked proud of myself for getting this one done, and I am not abandoning the project but the only way I see of keeping this system on track is establishing a solid reference point during each turn. I will still have the “lost count” issue with my forward counts but with those being such bigger numbers, the inaccuracy will be much less obvious. To cut to the chase, I simply gotta get a compas. This will eleminate all counts during turns, and will zero-out the turn count each time the direction has changed. I do have to say that when I do get ahold of a compas, most of the work I have done so far will carry-over quite quickly. I have already posted a “begging for parts” post which has not been fruitful thus far --I’ll probably just have to find an extra 45 bucks somewhere.

At any rate, I don’t see any reason to post my results as I have them now, I will do a proper post when I do get a compas and start getting cleaner maps. --Thanks for everyone’s help on this one.

15

would love to see a dirty map

"dead reckoning" has its flaws. We knew that when we went down this road. Could you post a flawed map nevertheless? I’m curious.