OpenServo.com Forum Index OpenServo.com
Discussion of the OpenServo project
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

I2C and Microcontroller Configurations
Goto page 1, 2  Next
 
Post new topic   Reply to topic    OpenServo.com Forum Index -> Applications
View previous topic :: View next topic  
Author Message
robotjay
co-admin


Joined: 01 Aug 2006
Posts: 225
Location: Nebraska, USA

PostPosted: Mon Mar 12, 2007 5:41 pm    Post subject: I2C and Microcontroller Configurations Reply with quote

Cliff briefly mentioned the following in another thread. I wanted to explore his ideas a little further without going off topic within that thread.

"Cliff" wrote:
I personally believe that I2C was and is the best choice for OpenServo. Its cheap and is reliable enough if care is taken in putting the bus together - bus signals routed as twisted pairs with grounds. If I were designing a complex robot, I would organize it with I2C local branches of 3 to 6 servos/sensors, run 4 of those branches into 'body processors' and have USB or ethernet from those processors to a hub connected to the main brain. I'm a fan of the idea that right way to do robots is to use many processors and develop the concepts of muscle memory and body language. If every twitch detail has to come from one processor, very serious bandwidth is needed everywhere, but if the job is shared out, simple low bandwidth buses make sense down at the motor level (where it takes milliseconds for anything to happen).


This is an excellent idea, and one that I have personally been kicking around in my head. Cliff mentions using USB or ethernet to communicate with the sub-controllers. What would it take to make this a reality?

My first thought is to use a central ""brain"" CPU such as a Gumstix. Which in turn connects through USB to Barrys USB-mega-I2C adapter (or something similar,) which in turn connects to several sensors/servos. Any thoughts?


-Jay
_________________
"Nothing is fool-proof; For we fools are ingenious and will find a way."
Back to top
View user's profile Send private message Send e-mail Visit poster's website
poor-robot



Joined: 09 Mar 2007
Posts: 45
Location: Portland, OR

PostPosted: Mon Mar 12, 2007 5:59 pm    Post subject: Reply with quote

A shortcoming of the gumstix is that there is no USB host option that I am aware of. Ethernet is a possibility with a gumstix but then you have to create a Ethernet-I2C, which is definitely possible but starting to look a little nuts.

You could get an ARM9 like the new AT91 series with USB host but the cost is $15 just for the processor. I can't afford numerous $15 processors on a small robot.

I'm going to start sounding like an evangelist soon but I think RS485 would be a very nice intermediary. With an AVR and an RS485 transceiver (AVR +$2) you have a two-chip translator from UART serial to I2C that could potentially operate up to one or two Mb/S on the input side. It's much cheaper and simpler than Ethernet, CAN, or USB and most of us already know about UARTs.

USB is still far and away the nicest way to get into a PC, but with a recommended cable length limit of something like 16' vs. 1000m for RS485 I'm not sure it's ideal for extended use.
Back to top
View user's profile Send private message Visit poster's website
ginge
Site Admin


Joined: 14 Jan 2006
Posts: 1031
Location: Manchester, UK

PostPosted: Mon Mar 12, 2007 6:43 pm    Post subject: Reply with quote

hey guys. this a very apt thread for me as I have a gumstix as well as a serial ans usb bridge. I think you have already nailed the problems with the gumstix interface... it has no host usb ans requires a breakout board to access the I2C.

I decided to use the gumstix as my main host controller as it has the ethernet bridge, and I can connect a whole host of gumstix units to the ethernet bus. I have already created a telnet server that runs on the gumstix as an i2c bridge. I would not recommend this route, however as it is fiddly.

after the hardware thread on the v3 page, I have decided to investigate RS485. I think this sort of interface would work well for this. thoughts?

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
robotjay
co-admin


Joined: 01 Aug 2006
Posts: 225
Location: Nebraska, USA

PostPosted: Mon Mar 12, 2007 7:06 pm    Post subject: Reply with quote

After reviewing the Gumstix documentation, I see that there is indeed no USB host control currently available. The Gumstix wiki says that USB 2.0 host control will be available in their next gen, but who knows how long it will be before they release it, or how expensive it will be (Gumstix are already on the expensive side.)

I have no experience with RS-485, although I am certainly not opposed to using it. Can anyone post a link to a site with good information on it?

-Jay
_________________
"Nothing is fool-proof; For we fools are ingenious and will find a way."
Back to top
View user's profile Send private message Send e-mail Visit poster's website
poor-robot



Joined: 09 Mar 2007
Posts: 45
Location: Portland, OR

PostPosted: Mon Mar 12, 2007 7:20 pm    Post subject: Reply with quote

I have a lot of experience with it - the company I work for uses it as a standard bus. For a good part of my day job I design devices that hang off an RS485 bus.

It can look complicated, but it is just a differential conversion of a UART signal. Your microcontroller hooks up to TX, RX, and TXEN/#RXEN and it is on the bus. You set TXEN high to transmit and then it's just UART. There will be some overhead we'll have to create such as packet addressing and header format, but it's not difficult.

The following site is a good intro, but a little overly-cautious. A few things won't be necessary - the 100 ohm ground resistor is only really an issue if you are connecting two earth-grounded nodes. The termination resistor is also generally a non-issue over short (10m) runs with low rates (< a few Mb).

http://www.circuitcellar.com/library/ccofeature/perrin0799/index.asp

We could also (I guess obviously) bootload over it, which creates a really neat update process where you just push one image onto the main processor. The main board can then push images down the bus onto devices which can then pass them along to sub-devices (in this case the servos over I2C).
Back to top
View user's profile Send private message Visit poster's website
ginge
Site Admin


Joined: 14 Jan 2006
Posts: 1031
Location: Manchester, UK

PostPosted: Mon Mar 12, 2007 8:40 pm    Post subject: Reply with quote

poor-robot,

This would suit my needs well. My I2C bus is going to have some motors and some simple I2C sensors, so I am going to run into bus speed and >127 device count issues unless I star off.

I just read TIA/EIA-485-A specification, and although it infers some kind of black magic voodoo is needed in certain topologies and uses, I think it would be fairly easy to work with once I got into it.

You mentioned packetising the protocol layer... any suggestions? Can you point me to any links with a pre existing scheme I can re-implement, or should we thrash something fresh out here?

Thanks

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
poor-robot



Joined: 09 Mar 2007
Posts: 45
Location: Portland, OR

PostPosted: Tue Mar 13, 2007 10:43 pm    Post subject: Reply with quote

I think I can provide enough data to get us rolling. A packet format such as the following could serve well:

[Header(Byte)]
[Device ID (Byte)]
[Packet_Size(Byte)]
[Data (up to 256 bytes)]
[16-bit CRC]

You generally would try to choose the header (0x01 is often convenient) to be a value that would not be often otherwise on the bus or 0x00 or 0xFF. You then look for the header followed by your ID and if not present you ignore everything up until the next header byte. If you get your header followed by your ID you CRC to verify and operate on the contents.

Obviously it will have to get more specific, but you could probably wrap whatever is easy for the packet handler code into the Data section.

What do you think?
Back to top
View user's profile Send private message Visit poster's website
mpthompson



Joined: 02 Jan 2006
Posts: 650
Location: San Carlos, CA

PostPosted: Wed Mar 14, 2007 6:15 pm    Post subject: Reply with quote

I guess time for me to chime in here. Hopefully I'm following the conversation correctly.

For a differentially driven UART protocol I would suggest using 9-bit data words. The high bit in each word determines if the lower 8 bits are address or data. The nice thing about such a protocol is the AVR UART supports such a multi-processor communication mode in hardware using the MPCM0 bit in the UCSR0A USART register (page 185 in the '168 data sheet). This would allow the MCU to ignore data packets not specifically addressed to it and dramatically decrease the overhead of a multi-drop UART protocol on each slave in terms of interrupt processing.

For something unrelated to OpenServo, I'm working on just such a multidrop protocol for an ATmega168 on a differentially driven serial bus (CAN physical layer rather than RS485).

-Mike
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger
poor-robot



Joined: 09 Mar 2007
Posts: 45
Location: Portland, OR

PostPosted: Wed Mar 14, 2007 6:40 pm    Post subject: Reply with quote

That sounds really nice for getting out of the data stream. How well does it interface to a PC with 9-bit data frames? Would it possibly interfere/be confused with XON/XOFF flow control? It sounds great for processor-to-processor, but I don't want to preclude being able to come directly out of a PC and into the 485 bus.
Back to top
View user's profile Send private message Visit poster's website
mpthompson



Joined: 02 Jan 2006
Posts: 650
Location: San Carlos, CA

PostPosted: Wed Mar 14, 2007 7:55 pm    Post subject: Reply with quote

The work I'm doing is with regards to some RoboBricks2 slaves that I described in another thread. In this case there is a specific module that converts standard 8N1 serial to 9N1 address/data serial instead of a direct wire connection. The module also handles the 115 Kbps to 500 Kbps conversion between the serial streams as well as some buffer for debugging the bus.

If the baud rate mismatch were not an issue, I'm not certain if a PC UART can do 9 bit data or not.

-Mike
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger
poor-robot



Joined: 09 Mar 2007
Posts: 45
Location: Portland, OR

PostPosted: Wed Mar 14, 2007 8:34 pm    Post subject: Reply with quote

Turns out electronic design has an article on just such an issue:
http://www.elecdesign.com/Articles/ArticleID/6245/6245.html

It is a little bit of a hassle because you have to reconfigure your parity settings on a byte-by-byte basis, but it looks like it should work. The PC has plenty of horsepower so I don't think it will be a bottleneck. This looks like a good way to go.
Back to top
View user's profile Send private message Visit poster's website
bren



Joined: 01 Jul 2007
Posts: 79

PostPosted: Thu Aug 16, 2007 9:17 pm    Post subject: Reply with quote

Hi all

Has anyone worked any more on this. I'm going to use my gumstix as the main processor and have 4xAtmega168 controlling the the openservo's. I'm also going to have a couple of Atmega168 reading and taking care of the sensors.

What is/was peoples finding/experience. has anyone got a good set up.

I've read through the docs and 2.5 mb/s is very fast, I'm just wondering what protocol people are using.

Would people be up for making this a community project as the standard interface for the servo's. Or at least a rough guide of interfacing it all together.

Thanks Bren
Back to top
View user's profile Send private message
robotjay
co-admin


Joined: 01 Aug 2006
Posts: 225
Location: Nebraska, USA

PostPosted: Thu Aug 16, 2007 10:11 pm    Post subject: Reply with quote

Bren,

Your idea sounds great. IMHO, gumstix are probably the smallest and most powerful way to command OpenServos. Barry Carter has experience with them, and I'm sure he'll speak up soon.

While doing research so I could modify Barry's OSIF to be used as a robot controller, I came across the Arduino. Becuse this board has everything that I was looking for (ATMega168 controlled, GPIO headers, status LEDs, ISP header, and external power connector,) I ordered a couple. My intention at the moment is to investigate whether this can effectively control multiple OpenServos. If it can, then I will start supporting this as my controller of choice. We'll see how that goes...

Talk to you soon.

-Jay
_________________
"Nothing is fool-proof; For we fools are ingenious and will find a way."
Back to top
View user's profile Send private message Send e-mail Visit poster's website
linuxguy



Joined: 16 Oct 2006
Posts: 120
Location: Beaverton, OR

PostPosted: Thu Aug 16, 2007 10:38 pm    Post subject: Re: I2C and Microcontroller Configurations Reply with quote

robotjay wrote:
This is an excellent idea, and one that I have personally been kicking around in my head. Cliff mentions using USB or ethernet to communicate with the sub-controllers. What would it take to make this a reality?

Yes, Cliff's idea of using distributed processing is excellent. I am seriously considering this type of setup for all robots I build from now on where it would be useful. However, I would not want to move control of things too far from the main MCU or processor. I can see doing something like having a gait processor that talks to one or more leg controllers, with the gait processor talking directly to the main MCU. There could then be a sensory controller also talking direct to the main MCU. Other controllers could be connected to the main MCU as required - perhaps a navigation controller or even a multimedia controller. Of course, one could also connect in a hardware floating point controller.

There is already this chip sold by Acroname, which is just a PIC with custom software to read sensors and communicate via I2C to a host MCU. I want to tinker with a setup using one or more of this with a Linux based master controller.

8-Dale
_________________
No, Mr. Jobs, the BiPod is a ROBOT. It does not play music OR interface with iTunes.
The Dynaplex Network - Robotics, Open Source, Linux, and Technology Forums
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger
bren



Joined: 01 Jul 2007
Posts: 79

PostPosted: Sat Aug 18, 2007 6:25 pm    Post subject: Reply with quote

Hi all

I've been busy doing some research. But can't find the answers I want, I don't want to use the uarts on the gunstix as there max speed is 900 kbps which isn't that fast. So I was thinking about using the 3 SSP lines in SPI mode. The thing that is confusing me is that the gumstix uses 4 wires for it's "Motorola Serial Peripheral Interface* (SPI) protocol" these are:

NSSPSCLK
NSSPSFRM
NSSPTXD
NSSPRXD

The one that's confusing me is the Frame indicator as it doesn't appear to be used by the ATmega168.

The other bit of information that I couldn't find on the web is the speed that the the ATmega168 can run it's SPI line at. These no info in the docs about it's max speed to error rate.

Do you thing the two will work together?

robotjay - I've been using the Arduino for a couple of weeks and it's a lovely little stamp chip for prototyping (just finished my sensor circuit). Something you might want to consider if you haven't go them yet is the small USB to Arduino board. I played around for a couple of hours with the Arduino when I first got it trying to get it to work and had no joy so order the converter and it works like a charm.

Bren
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenServo.com Forum Index -> Applications All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group