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 

Robots with serial servos

 
Post new topic   Reply to topic    OpenServo.com Forum Index -> Applications
View previous topic :: View next topic  
Author Message
floli



Joined: 03 Jan 2006
Posts: 1

PostPosted: Tue Jan 03, 2006 12:14 pm    Post subject: Robots with serial servos Reply with quote

I found there are robots using serial servos linking up with RS485. Can I2C bus do the same job?

http://www.tribotix.com/Products/Robotis/Dynamixel/DynamixelIntro.htm

The maximum speed for RS485 is 10M bits/s while 400k bits/s for I2C. I am afraid I2C cannot control large number of servos (says 23 for Humanoid Robot) efficiency.


foli
Back to top
View user's profile Send private message
Guest






PostPosted: Tue Jan 03, 2006 3:01 pm    Post subject: Reply with quote

Foli,

Welcome to the OpenServo forum!!!

Because the ATtiny45 I am currently using the OpenServo is a relatively low powered microcontroller and the I2C implementation is partially implemented in software, the maximum speed we are likely to see out of the I2C bus will likely be 100KHz. However, I would love for someone to look over the I2C code and see if it could be driven to 400KHz.

Many of the other people interested in the OpenServo are current working on Hexapod robots where 18 servos are needed (3 servos for 6 legs). I myself have been thinking about a biped robot.

Your concern regarding the the bandwidth of the I2C bus for a complex biped robot is absolutely valid. However, the most useful aspect of the OpenServo project is that it will be developing open source PID and other motion control algorithms that can be applied to future servos that have diffferent communication capabilities. Given the challenges of this project, developing sophisticated motion control algorithms that complete with commercial digital servos is much greater than developing alternate communication protocols for the servo. I see our current choice of I2C is the fact it's relatively inexpensive to implement in parts (built into the AVR microcontroller) and meets the needs for many uses of the OpenServo.

If other buses would work out better, I see those being developed for the OpenServo once the hard task of implementing the motion control algorithms is complete and the basic premise of the project is proven.

I myself would have preferred to use the SPI bus which is simple as the I2C bus, but operates at 10 MHz, but would have been trickier to implement on the ATtiny45 because the I/O lines to implement SPI would conflict with the PWM and ADC lines.

Thanks for pointing out the Dynamixel servos, I hadn't seen those before. I'm always interested in how other people/companies approach a similar problem. For instance, their method of daisy chaining the servos is interesting. However, at $140 to $300 a piece, I'm hoping we can make a competing servo for most applications that would cost about $20 to $30, perhaps $40 for higher torque versions. Of course, you have to build an OpenServo, but that part of the fun :-).

Hopefully the points I made above make sense. I would love to see someone develop an RS485 version of the OpenServo project.

-Mike
Back to top
andylippitt
Site Admin


Joined: 02 Jan 2006
Posts: 155
Location: Denver, CO

PostPosted: Tue Jan 03, 2006 3:18 pm    Post subject: Reply with quote

One of the other concerns about I2C that we've been discussing is bus capacitance. Daisy chaining the servos together will help, but one of the other solutions thrown around solves this issue too. If we can't speed up the bus enough, break the bus into mutiple pieces. I know that Colin uses an FPGA controller with an I2C master for each leg on his hex to maximize the throughput. It doesn't take an FPGA with hardware I2C blocks. A very fast I2C master can be written in software for any micro. It's the slave where the timing is difficult.
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger
mpthompson



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

PostPosted: Tue Jan 03, 2006 5:42 pm    Post subject: Reply with quote

Regarding the I2C bus capacitance, there seems to be a number of solutions to this problem. Some solutions could involve eisther I2C driver chips or an I2C bus multiplexer such as the following from Philips:

http://www.semiconductors.philips.com/pip/PCA9547BS.html

Each like could be controlled by an independent I2C bus with all legs connected to a single master via the multiplexer.

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


Joined: 02 Jan 2006
Posts: 155
Location: Denver, CO

PostPosted: Tue Jan 03, 2006 5:52 pm    Post subject: Reply with quote

that addresses the capacitance problem, but the benefit of the bus being broken entirely also addresses the throughput issue
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger
guru



Joined: 03 Jan 2006
Posts: 128
Location: St Pete Beach, FL

PostPosted: Tue Jan 03, 2006 6:34 pm    Post subject: Reply with quote

Running SPI at 10MHz would also cause a lot of interrupts in the PIC or Atmel that could adversely affect the PID bandwidth. I think the I2C is fast enough and should have muliple buses if you need higher throughput. My 2cents.

I do like using FPGAs. I can put one in my system as a host peripheral controller even before I know what I am going to do with it. I just starting wiring it to everything and worry about wiring the inside of it later. As long as I wire the PIC to my periphs and sensors I dont have to make a pcb change after. Once I make one i2c module block I can just reinstantiate it for each leg. I would also rather deal with a directly addressable i2c host controller (ISA or PCI) than bring rs232 or the like into the middle and have to translate protocols in software. But, then I like programming VHDL! Wink
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
mpthompson



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

PostPosted: Tue Jan 03, 2006 6:52 pm    Post subject: Reply with quote

Colin, in your servo is your I2C implementation polled or interrupt driven?

Currently, on the AVR based OpenServo I2C processing is interrupt driven. I have noticed the interrupts can interfere with the PID throughput if I'm constantly pulling data from servo such as when I'm gathering stats data to tune the PID algorithm. I'm considering moving to a polling implementation (just as I did in my bootloader) where I2C processing is limited to occuring between PID iterations. I think I would prefer to slow down I2C performance it it allows better overally servo functioning.

On the AVR, the I2C (or TWI as they call it) implementation has hardware assist, but is still partially implemented in software. Interrupts occur after the transfer of each byte. Therefore, I believe the overhead of implementing SPI or I2C on the AVR is about the same.

One thing I don't like about SPI is it requires a select line going to each peripheral. This can be compensated for using some tricks, but it's still not very pretty.

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



Joined: 03 Jan 2006
Posts: 128
Location: St Pete Beach, FL

PostPosted: Tue Jan 10, 2006 10:35 pm    Post subject: Reply with quote

My pic i2c is interrupt driven. But since I changed my code around I havent noticed any interference with the PID loop. However, as far as we discussed earlier my new code design is more similar to yours where the timer interrupt changes a flag that the ""user space"" PID loop watches for. I run my dimax at 100KHz now without any freeze-ups or overruns.

I calc'd the number of cycles any path through my i2c routines take and I have more than enough idle cycles within each PID loop to do it. I put a performance counter in my servo to detect instances where the PID loop took longer to calculate than the timer interrupt, and it doesnt move unless I run the timer clock to quickly.

I am looking forward to seeing the practical results of all your experiences with each of the ""closed loop"" routines. Your load tests and different algorithms is something I havent gotten to yet. Perhaps if there are a few good candidates the algorithm can be choosen based on an #ifdef condition placed inside a config file.

C
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
DavidCary



Joined: 24 Oct 2007
Posts: 12
Location: Oklahoma and Kansas

PostPosted: Wed Oct 31, 2007 6:35 am    Post subject: Reply with quote

Quote:
The maximum speed for RS485 is 10M bits/s while 400k bits/s for I2C. I am afraid I2C cannot control large number of servos (says 23 for Humanoid Robot) efficiency.


My understanding is that
RS485, I2C, and SPI all can run at a wide variety of bus speeds.
Some people run a particular interface at 4 Mbit/s; other people use the same interface at 4800 bit/s.
So it's unfair to rule out any one of them as "too fast" or "too slow".

The question of "which interface to use?" and "how fast should the interface go?" are 2 related but separate questions.

how fast

Human reaction time is typically around 200 ms (sometimes much longer). Driving a humanoid robot at that update rate with a "mere" 100 Kbit/s bus, that's enough time to send 10 bytes of commands, reads, and writes to up to 250 servos on a single chain.

andylippitt points out that one would design shorter chains for other reasons.
So 100 Kbit/s at least *seems* fast enough for human-like motion.
(But super-human hummingbird-like motion would be cool).

which interface

Quote:
One thing I don't like about SPI is it requires a select line going to each peripheral.


One thing I *do* like about SPI is that 4 pins on the master can drive any number of peripherals, without any need for "programming addresses" or "individual peripheral select lines", as long as all the peripherals properly implement daisy chaining.
By "peripherals that properly implement daisy chaining", I mean something like the ADS1271 and the 74x595.
I see no reason why OpenServo couldn't be re-programmed to properly implement daisy chained SPI.

As a side effect, daisy-chained SPI peripherals automatically get a "sync" pulse ("frame" pulse), which can be used to make sure all the servos are synchronized to move in unison.

-- DavidCary
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
Page 1 of 1

 
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