Australia
Asked — Edited

I2c Servos Instead Of Pwm Servos

I'm developing new servos with a mechanical engineer and we've decided to make them i2C to reduce the number of internal wires per module.

How do I run ARC with i2c daisy-chained servos?

How do I connect a 'send wire' from the daisy-chained servos to the EZB-V4 using i2c for position feedback (pose programming)?

My continuous rotation servos will use magnetic encoders and exceed the ARC (potentiometer dictated) 180 degree limits. How can I hack past this in ARC to rotate my servos a couple of thousand degrees for example?

Thanks


ARC Pro

Upgrade to ARC Pro

Subscribe to ARC Pro, and your robot will become a canvas for your imagination, limited only by your creativity.

PRO
USA
#1  

EZBuilder's servo controls and EZScript servo command/functions are only for PPM Analog/Digital servos, connected to the EZB's digital ports.

your I2C custom servos are treated as I2C slave devices.

to control the I2C custom devices you will need to use EZScript and I2C functions e.g. I2CWrite, I2CWrite etc.

code example:


#first you identify the i2c slave addresses (your custom servos)
$addr_servo1 = 0x20
$addr_servo2 = 0x21

#command example byte codes
$cmd_position = 0x01
$cmd_speed = 0x02

#set speed 5 for servo1
I2CWrite(0, $addr_servo1, $cmd_speed, 5)

#set servo2's position to 360
#  Note: 360 needs 2 bytes
$position = 360
I2CWrite(0, $addr_servo2, $cmd_position, $position>>8, $position & 0xff)

bear in mind, for the ARC you are controlling i2c devices, not servos.

PRO
Synthiam
#2  

I'd create a plugin (take a look at the dynamixel plugin). It simply binds to the V ports. The V ports are virtual for this exact use case.

The i2c wires on the plug are in the datasheet

I wouldn't use i2c due to the speed limitation, physical protocol fragility, and the number of wires.

Make them uart and it'll fly! Say 256kbps

As in ptp's example - it would be more efficient to combine the two commands into one i2cwrite due to the way i2c works. There are start and stop signals with clock synchronization - it all takes time. So reducing the number of I2c writes will save a bunch of time.

But, I would not use i2c at all for servos.

PRO
USA
#3  

@DJ,

One quick question servos on V ports are limited to 180 degrees too ?

he wants to daisy chain the servos, i believe it's possible to use only the TX from the EZB, and all the servos listen on the RX.

I never tried.

PRO
Synthiam
#4  

a plugin can modify the max servo positions, which will affect the entire environment.

Off hand, I believe it is EZ_B.Servo.SERVO_MAX

Australia
#5  

Wait, are you saying that i2c is no good for daisy chaining servos? I was simply told by a robotics professor, but I'm not sure who to follow. PWM doesn't allow daisy chaining. Does UART? I've only personally used PWM so I have no idea about any of these other things: PPM, i2C and UART.

Can you tell me about UART?

Australia
#6  

http://stackoverflow.com/questions/21469647/uart-vs-i2c-vs-spi-for-inter-processor-communication-between-microcontrollers

A stack overflow guy says SPI is the best... Now I'm really confused.

Australia
#7  

These servos have 3 types of connection: http://robokits.co.in/motors/high-torque-encoder-dc-servo-motor-60rpm-with-uart-i2c-ppm-drive

How many of these could I daisy chain together in UART? How would I make them work with the EZBV4 and ARC?

Would this Dynamixel plugin make any UART servos work easily? https://synthiam.com/redirect/legacy?table=plugin&id=39

User-inserted image

PRO
Synthiam
#8  

UART allows daisy chaining - because that would be application protocol dependent. Where i2c is hardware support for daisy chaining.

For example, look at the dynamixel protocol which uses UART. The dynamixel plugin is open source, so feel free to take a look at it.

In the dynamixel protocol packet, there is a byte which is the address of the servo that the packet is destined for.

Here's an example of a packet which you could start from that i just came up with...

[feature] Byte 0 <- size of packet in bytes not including this header Byte 1 <- address of servo (255 means all servos listen, otherwise 0-254 servos can be daisy chained) Byte 2 <- command (look at reference #1) Byte 3...255 <- data (dependent on command) [/feature]

and here is an example of available commands... [feature] Reference #1

0 <- move servo (accepts 16 bit unsigned int positioning) 1 <- set servo speed (accepts 16 bit unsigned int speed) 2 <- move servo & set servo speed (accepts 16 bit unsigned int positioning & 16 bit unsigned int speed) 3 <- change led color 4 <- release servo 5 <- change baud rate (accepts baud rate as 32 bit unsigned int) 5 <- reset servo to default parameters [/feature]

And here would be an example of moving all servos to position 50 [feature] 0x04, 0xff, 0x00, 0x32 [/feature]

And here would move the third servo to position 200 and set the speed to 80 [feature] 0x06, 0x03, 0x02, 0x00, 0xc8, 0x00, 0x50 [/feature]

With UART, you only need 1 wire for data. With i2c, you need 2 wires and specific resistance values that are dependent on the i2c protocol - which means chaining servos and the length of the wire will decrease reliability. Also with i2c is that noise affects communication. Lastly, i2c is incredibly slow compared to uart. And UART can allow baud rate specification.

Regarding the motors you posted - i have no idea if they have a protocol created for daisy chaining. Look at the data sheet or contact the manufacturer for more information regarding your requirements.

Australia
#9  

Thanks DJ, that code looks foreign to me right now, but my tech guy probably understands it.

UART uses bidirectional communication as well so I can physically pose a robot easily and save a frame, right? So that the servos can tell the computer their rotation location? I think thats called 'positional feedback', but I've heard positional feedback is what all servos do even with unidirectional communication so I'm not sure of the correct terminology. And using a magnetic encoder we can rotate, say, 2,489 degrees and the servo will understand, right? Also, how many UART devices can be chained from an EZBV4? And is there a picture of how to attach it to the board? (It looks like the robot may be drawing up to 60A per arm, so Im sure the EZB needs to be bypassed for servo power.) Also, there seem to be a lot of different UART protocol types, including USART.

ptp wrote this here: https://synthiam.com/Community/Questions/9672&page=3 <- This page is very much related to the technical side of protocols.

Serial Communication: the clock is predefined: Full Duplex - 2 wires: TX + RX Single direction: 1 wire (Tx->Rx) Half Duplex - 1 wire (e.g. Dynamixel 1 Data pin) Half Duplex - 2 wires (e.g. Dynamixel 2 Data pins - Differential Signaling) RS485 Full Duplex - 4 wires (RX-2 TX-2) RS485 Single Direction: 2 wires (TX->RX)

Pretty confusing.

Another thing I need to understand is how servos can self-calculate how much to increase their speed to arrive at a pose in time with the music. If I pose a robot and save it's pose on a beat of a song, I haven't been able to make it arrive exactly on the beat. I only know how to make it sleep between frames, which means holding off the next command. But of course I need it to obey every command, but adjust its own speed to get to the frame afterwards by the timecode of the song. Imagine the choreography for the song 'YMCA'. Y, M, C and A are not spaced evenly apart. The robot needs to land the correct pose at the exact timecode. How is this usually achieved without unnecessary maths to calculate hundreds of speed changes per song?

Also, as I've discussed before in a thread about controller types (https://synthiam.com/Community/Questions/9624), voodoo control would be acceptable for programming. This could mean using a much cheaper pose doll thats connected to the main robot, and the moves can be programmed both frame by frame or live. Would a voodoo controller work with UART and EZB? How would you hook it up?

PRO
Synthiam
#10  

Your tech guy will fill in those questions for you :). Good luck!