Proteus
Portugal
Asked
— Edited
Hi DJ, i think some kinde of encoder plugin would be great. There are basically to encoder types: optical or mechanical. What do you think?
Hi DJ, i think some kinde of encoder plugin would be great. There are basically to encoder types: optical or mechanical. What do you think?
What would you want it to do?
There are a couple of different types of encoders, but most are those that incrementally count up or down based on the signal sequence (a or b channel rises or drops first). Would you just want to see how fast it is counting or would you want to be able to use it to drive your robot?
There are also a lot of different encoders. Some have one channel, some 2, some 3 and so on. Each type would require specific code to account for the type of encoder that it is. Also, some have Index which would then let you set two motors to the same location pretty easily and reset the counter to 0, but not all have index.
Please expand on your idea so that people can understand what you are looking for. I use encoders, but they are managed outside of ARC. I would expect that an encoder with a very precise measure would send back a ton of data. Something with a pretty low resolution would not send back much and would probably be possible.
In a mobile robot with high resolution encoders for its wheels, I would think that it would be better to use some sort of subsystem to do this instead of sending this information back across wifi, but that is just me. I would be interested in your thoughts and how you would see it being used.
Hum, that wi-fi issue is a good point. What kinde of subsystem do you sugest? Regards
Paulo
A sabortooth with a kangaroo is a good option IMHO as long as you dont go over 40K pulses per rev per encoder/motor combo.
It could be done with an arduino (maybe mini pro) with a serial interface to the EZ-B also. This would be more cost effective and allow you to control it more granularity.
You could bypass the EZ-B all together and go straight to your pc with either of these options, which would reduce the traffic through the wifi.
The only reason that I mention this is my setup does about 80K pulses per second currently. That could be handled in the sub-controller to only pass back 1 in 10 or something like that and report back via serial through either the v4 or through a pc com port.