I just got my BaneBot 36mm encoders(pdf) all hook up and calibrated yet I am not fully sure how to work with the A/B signal lines.
I am trying to solve the issue of not being able to run a straight line, or compensate for mechanical imperfections, etc.
Any help getting started would be huge!
I do have them
I do in fact have 2 encoder divider boards. However, I am unable to get d1 to lite up for one direction and d2 for the other. Not really sure whats going on.
What happens?
So, what does happen when you wire up the encoder(s) and turn the shaft? Do the LEDs light up at all? Light up and stay on? Something else?
Encoder stuff
The encoder divider manual and the encoder assembly instructions both point to calibration if the D1 and D2 lights aren’t changing as they should according to the shaft rotation. The encoder instructions did also mention reading with an oscilloscope to check the signal, as another form of calibration. Not sure if you have access to an o-scope, but another possibility would be to connect the A&B outputs to a resistor and LED to ground, just to watch the changes as you slllooowwllly turn the shaft. You should see the sequence Oddbot mentioned above (either going up or going down depending on direction). If it looks ok, then there might be a problem with the assembled encoder divider circuit that should be hunted down.
I look at 4 ways to deal with quadrature signals. 1st is using a micro with quad decode capabilities. The New Micros Isopod (and other Pods) uses a Freescale DSP56F805 micro that has 2 default set-up quad decode inputs, for plugging in 2 pairs of A&B signals and directly reading a pair of memory locations that are automatically incremented and decremented as the encoders turns, in what is called 4x mode. This 4x mode means an encoder is read on every rising and falling edge to get say 2000 counts out of a 500 slot encoder. 2nd option is using an application specific IC like the US Digital LSFS266R1 dual quadrature IC to be read by the controlling micro as needed. 3rd would be a circuit like the encoder divider above, or some similar set-up, to be read by a micro directly. Last option would be to try to program the micro with a state machine sequence to determine count and direction of the encoders. Anachrocomputer has mentioned David Andersons info on the web and Dave has a txt file on odometry here that discusses a lot of info you seem to be looking for. Dave has a lot of good info on his very well developed robots too.
Yep
So I was told by BaneBots that since all I am looking to do is "balance" motor1 and motor2, that I can omit calibration and just read A/B signal for speed. I am however unaware how to do this. Does this sound accurate?
Is that all that is planned?
Do you wish to only balance the motors, or do you want the encoder counts to tell the robot where it is in relation to a goal? For me, I’d try to experiment with getting the quad encoders to work as quad encoders, not as simple tachometers. This would be so that I could use the added information for odometry calculations, to keep track of where the robot is.
Yes and no
Robologist- what you described would be wonderful. But given the fact that I have never worked with quad encoders, I am just trying to start small and work my way up. After tinkering yesterday and thanks to this forum, I think I now have a base level understanding of what I need to do to accomplish the "balancing act."
In order to remove complexity, I have removed the encoder divider boards and thus have no direction calibration, as of now (fine). I am reading the A signal lines from each encoder:
symbol M1Tick = b0
symbol M2Tick = b1
Then checking the logic level of each and incrementing their respective counters by 1 as they "tick":
if pin1 = 1 then
M1Tick = 1
Counter1 = Counter1 + 1
else
M1Tick = 0
Counter1 = Counter1
end if
if pin3 = 1 then
M2Tick = 1
Counter2 = Counter2 + 1
else
M2Tick = 0
Counter2 = Counter2
end if
Thats where I left off last night as the effects of the beer started to kick in.
Change to prevent run-on
As is, the code above would keep incrementing the count if the motor was stopped on a mark of the encoder. So it might be good to store a little "state " information about what the previous condition of the encoder was before incrementing the count. I used a variable you already had as a state variable, and took out what appeared as a redundancy. At some point the counter will probably need to be cleared to prevent over-run.
if pin1 = 1 AND M1Tick = 0 then
M1Tick = 1
Counter1 = Counter1 + 1
else
M1Tick = 0
end if
if pin3 = 1 AND M2tick = 0 then
M2Tick = 1
Counter2 = Counter2 + 1
else
M2Tick = 0
end if
Word
Yes, for sure. There is no timing element yet either. As in, I will be intersted in knowing for a given amount of time how many ticks occured, then adjust the motors accordingly, then clear all counters, repeat process.
Argh, still not right
Still didn’t think it through right. Maybe this, but still not addressing the timing as you say.
if pin1 = 1 then
if M1Tick = 0 then
M1Tick = 1
Counter1 = Counter1 + 1
endif
M1tick = 1
end if
if pin1 = 0 then
M1tick = 0
end if
if pin3 = 1 then
if M2tick = 0 then
M2tick = 1
Counter2 = Counter2 + 1
endif
M2Tick =1
end if
if pin3 = 0 then
M2tick = 0
end if
There, seeem like that should work to change a state variable, and only incrememt the count if the previous state of the encoder is different than the current state.
Thanks
Thanks Robo, I will be playing with the above this week. I will post back my findings.