go_away

Author Topic: serial protocol for motor controllers  (Read 1011 times)

0 Members and 1 Guest are viewing this topic.

Offline infurlTopic starter

  • Jr. Member
  • **
  • Posts: 14
  • Helpful? 0
serial protocol for motor controllers
« on: March 27, 2012, 05:21:56 PM »
I've been developing a simple "open" motor controller for a small differential drive robot which I've documented here:

http://infurl.net

Having got a rudimentary PID controller working I'm now researching methods for interfacing the motor controller to a higher level control element, currently a Chumby Hacker Board. I figure it would be worth the effort of defining a formal protocol to do this and I have been looking around to see if there is any sort of standard that I could adopt.

There seem to be quite a few different mutually incompatible protocols in use, but so far I haven't been able to find anything about development of an interoperable standard for motor control. The closest that I've found so far is on ros.org which has linux drivers for some different motor controller boards.

Examples of serial protocols:

http://www.robot-electronics.co.uk/htm/md25ser.htm
www.roboticsconnection.com/multimedia/docs/Serializer_3.0_UserGuide.pdf
http://www.surveyor.com/SRV_protocol.html

ROS drivers:

http://www.ros.org/wiki/Motor%20Controller%20Drivers

Does anyone know of any efforts to develop such a standard? How about proprietary protocols which could be brought into the open? If an open motor control protocol is to be developed from scratch, what sort of features should it have?

Offline joe61

  • Supreme Robot
  • *****
  • Posts: 417
  • Helpful? 16
Re: serial protocol for motor controllers
« Reply #1 on: March 28, 2012, 06:47:48 AM »
This is just my opinion, but I think that an API, like you seem to be talking about, would make sense for something running an operating system that has libraries and/or device drivers. One or both of those would provide a level of indirection necessary to interface a standard API with devices by various vendors.

With little 8-bit chips like we normally talk about here, the chip is all there is, so it has to have knowledge of the vendor's API to the device. Unless we could get the various manufacturers to all use compatible interface protocols, we're left with what we have.

Edit: You could provide the equivalent to device drivers or libraries with additional chips. If you program a chip to know how to talk to a particular device, then provide an API to it (with I2C or whatever), you could control multiple devices from various vendors with one API. That's kind of the same thing as stuff like this. It may or may not be more expensive than desired, or take up more board space than desired, but that's one way to go.

Joe
« Last Edit: March 28, 2012, 06:58:12 AM by joe61 »

 


Get Your Ad Here