I’d be interested in porting some version of this library to the Gadgeteer/.NETMF devices. This thread looked promising, but appears to be abandoned, with no recent news. The link provided by Gus to his solution is no longer accessible as the www.microframeworkprojects.com site appears to be down. Has anyone had success in this area? Are any solutions available for the hardware/software/driver issues? I’d certainly love it if someone has already solved the problem and provided a high-level C# library. But I’d also be happy to pick up where others have left off and share whatever work I do. Perhaps even a Dynamixel Gadgeteer module would be of interest?!
Thanks for the quick response! I had seen that, and understand the approach, but I was actually hoping for (while not expecting) a bit more detail, in particular WRT the FEZ Spider. But I assume that between your Spider schematic and the LPC24xx User Manual I can figure out which socket and RX/TX pins to use given the COM port and registers you’re using. I also assume prototyping with the extender board is a reasonable first choice. I’ll have a go and see what I can do!
Did you get anywhere with this? I have a Parallax Motor mount with position controller that I want to control via a single wire, half-duplex UART. I can build the circuit that Gus mentioned early on in the thread, but if there’s a simple software solution, I’d rather use that.
The ‘new’ encoders included with this are pretty standard opto’s; the signal is high when the beam is not blocked by the encoder and low when it is.
The bottom of that PDF explains how to interpret them.
Other than that, it appears you just supply current to the motors; reverse polarity reverses direction of spin.
Seems like once either line determines that the wheels are turning and shouldn’t be (rolling downhill), you’d only need to sample both lines to determine which direction you should accelerate to apply the ‘brakes’ until you successfully stop. You could, then, resume watching only one of the signals for width/frequency/count. Right?
I might be missing something… Is there a reason to sample both lines all the time when the PIC is already aware of the spin direction?
Also, does it seem odd to you to have 2 separate power and ground connections just because there are 2 signals? Why not a single 4-pin connector??
Depending on the controller you use it can be either PWM or serial. Or instance if you use http://www.ghielectronics.com/catalog/product/315 then a PWM signal is sent to the motors to turn and a digital pin is used for direction - this is all done via the driver.
The best way to go is to use a dedicated DC motor controller to drive them due to the loads etc involved.
You can use interrupt pins to count the pulses for the encoders but Netmf is not the best for this as you will lose pulses when it starts doing house keeping etc, and yes you need to constantly monitor both A and B channels.
What you want is a dedicated module to do the quadrature stuff.
Most encoders i have seen usually have 4 or 5 pins +5v, GND, A and B with an option index.
