ARC Pro

Upgrade to ARC Pro

Unlock the true power of automation and robotics by becoming a proud subscriber of Synthiam ARC Pro.

#1  

I'm using an hdmi cable and hdmi breakout board instead of this. I run power to my servos on a separate feed.

PRO
Synthiam
#2  

I would highly recommend not using a ribbon cable for the servos. That is very dangerous and will most likely melt the coating and hopefully burn the very small wires before lighting on fire.

The Extension Cable that we offer is best for this application because, as Richard R said when he saw them "those aren't cheap China extension cables" - he's correct, we chose very high quality cables.

#3  

Good catch! My bad....wasn't thinking....as usual....:D Nuff said....

#4  

@d.cochran...

What is the wire gauge in the hdmi cable?

#5  

You can't use very large gauge and get it through the joints in the inmoov. I am limiting the hdmi cables to 3 feet because of this. Also, and I can't stress this enough, I am running the power through 14 gauge wire to the location of the 6 hand/wrist servos. This isn't going through the ezb but uses a common ground to the ezb. Each ezb in my build has no more than 9 servos attached to it with only 4 of them getting power directly from the ezb. These 3 of these 4 don't have extensions as they are close to the placement of the ezb. Only one servo has an actual extension which is the one in the elbow.

I should also say that the ezb could probably handle the load of the 9 servos without an issue. I just am trying to keep from having a lot of wires passing through the joints.

PRO
Synthiam
#6  

My InMoov is running all of it's servo (except fingers) through the ez-b. It can do it, but if you want more efficiency, I would recommend running separate power such as d.cochran is doing.

Also, the hdmi cable is not good for power - obviously, but it's great for signal:) That's what d.cochran is doing as well. He's running only the signal through the hdmi cable and the power is separate.

#7  

@d.cochran... Thx for the info

#8  

It's true, I have "those" cheap Chinese servo extension cables off of eBay.... They are barely good enough for sensors let alone servos... I saw the ones Jeremie was using and they are solid... My next order with ez robot I plan on buying a couple of 10 packs of them....

@David, I really should be adopting your method of a central power hub for the servos... However, saying that, I did have all the large servos (12 in all) plugged in directly to my ezb's ports.... It handled it like a champ.... :) I was using an ssc-32 for the hand and wrist servos.... maybe not the best or most elegant way, but it did take the load of the ezb... However, now that ARC supports the ssc-32 everything can be added to the auto positioner control... It makes the ssc-32 much more usable...

PRO
Synthiam
#9  

Richard, that's what forced me to create the SSC-32 control in ARC. It was a pain in the butt coding for the SSC-32 directly. I really wanted to use it in the Auto Position, now we can:D

Guess that's how you get me to do stuff... Give me something that's frustrating and i'll make it happen to make my life easier Hahaha

#10  

It's great stuff man... I have seen you code first hand so I know... LOL... The Auto Position now supports 56 servos.... Geez, with that many servos you can have your inMoov performing brain surgery with that much articulation... I do wish that the power connectors on the ssc-32 would fit larger gauge wires... The connector seems like to be a power bottle neck to me...

#11  

yes, but think about this. With 5 ez-bs, you could have 280 servos now. That is crazy.

PRO
Synthiam
#12  

Haha - that's nuts! never thought of that:D

#13  

Nice , I'm glad to hear EZB supports the scc32 board now , that really expands the amount of servos! Fantastic

On a second note , what guage cable is the ext cable in the ez robot store? Also is it copper or tin? Just wondering , Thanks

#14  

@Josh... I am not sure what kind of wire, but they are at least the same gauge as the lynxmotion ext cables.... However, they may even be a lower gauge (thicker) because they do feel more substantial than the lynxmotion cables...

p.s.... Josh, I still plan on getting some of those regs off of you.... I'll eventually get around to it LOL....

#15  

@RichardR -

I just got an ssc-32 and I have a question. I'm trying to use a horizontal slider to move a servo on the ssc. I can see the communication led blinking on the ssc and I do have a power light on the "a" side of the ssc. I have port V0 selected in the slider. I do not get servo movement on the ssc.

My question is am I configuring correctly? On the ssc control I have "is ezb uart #0" checked. On the slider I have port V0 selected. That doesn't seem right to me but I'm not sure how else you would configure. For instance, configured like that, how would I pick the B side of the ssc? Also, any projects you have written for the ssc and a hand would be appreciated.

I did see the example script you posted once and will try that, I was just trying to do it with a slider to start.

#16  

@Checksumff Do you have the baud (confirmed) set at 38400? Also do you have the UART wired to the SSC-32 correctly? What version of the SSC-32 do you have? I haven't tried using a basic servo movement with the SSC-32 yet... I have been controlling mine with serial script commands...

Sample code to send serial commands to move servos on ports 0 - 4 on the SSC-32...


$pw="750" #position min is 600 max is 2400, 90= 1500
$m ="1000" #speed command

UARTWrite(0,0,"#0P"+$pw+"S"+$m,13) #right thumb
UARTWrite(0,0,"#1P"+$pw+"S"+$m,13) #right index
UARTWrite(0,0,"#2P"+$pw+"S"+$m,13) #right middle
UARTWrite(0,0,"#3P"+$pw+"S"+$m,13) #right ring
UARTWrite(0,0,"#4P"+$pw+"S"+$m,13) #right baby

#17  

@Richard - Mine is the USB version, I will check the baud rate immediately. I assumed since it was blinking green it was communicating. RX to TX. I'll let you know.

#18  

I just bought the new USB version.... Check the PDF manual for it... It will show you how to change the baud rate... I think by default it is set at 9600...

#19  

Yup, it was baud. The instruction said a blink green means it received the packet properly so I thought I was good. Thanks for the suggestion.