UBTECH Alpha Servos UBT-12HC

Synthiam doesn't make any hardware. You'd have to talk to the manufacturer of the product you're using. In this case, it's an EZ-B v4 made by EZ-Robot.

Synthiam makes software, called ARC.

I didn't know that   Synthiam   and Ezb were different things. I wondered why Ezb , I have known for years,  some time ago had decided to add this  new name to itself !... Now I know.

I discovered the cause of the hardware problem. EZB v4 and Iotiny have a current limiting resistor for each digital pin  (see datasheet) !!! This prevents excessive load. But the problem can  easily be solved by an extra chip in the robot.   No need to ask EZB. They probably didn't imagine the high load to output pins  caused by third party's hardware of all kinds.

Please, provide an option in the plug in , to use  Iotiny and its software uart   too. Latest plug in is  for ezb v4, with  hardware uart . Iotiny is very small ,  perfect for alpha robot ! This option is needed.

It has that function already. Please read the manual on this page. The description of using IoTiny and any other ezb is specified. This is already written in this manual for this plugin.

Please use the config screen to adjust settings...

Bad news DJ !... I'm testing this plug in with iotiny. It seemed to work well,  but, in repeating actions ,  the further positions  of servos  tend to change in an apparently  random way....It's the same problem observed  with the  bluetooth plug in !

As you know , ubtech servos are bidirectional , i.e they send back their position, on the same control line. Ipothesis. Perhaps the servos need some validation of this feedback from the controller, to be able  to go to next positions ? To make a comparison, there is a plug-in for 4-wire serial bus servos (dynamixel). Did it use the feedback wire in some way ?

Of course to do something like that with ubtech servos,  hardware and software should be quite different,  but  this is not a problem, I think.

No, dynamixel servos do not require feedback. Additional information from the manufacturer is necessary to continue on these servos and with this robot. If you obtain information, let us know

Hi Dj. Despite the latest non promising events, i'm anyway going on investigating. I had seen that, in the auto movement window,  clicking  "execute" for the action , or  "transition to"  for the frames,  servos didn't  move correctly .  But now i discovered that, if i use  "Jump to" a frame , the movement is always correct and fast and never fails. Actions are actuated in a different way (delay, steps, speed). I changed these parameters in various ways, but i could't get the same speed  as in  "jump to". If  actions and frames were actuated as fast as in "Jump to " mode, everything might work. Please tell me if this is possible in some way.

Servos aren't permitted to move slowly, they must move fast , because they  seem to have a time-out . After some time, they stop , no matter if the final position is reached or not. Subsequent movement starts where they stopped , not from the right position, and all becomes  unexpected.

I looked at the the bluetooth protocol,  (command to position a single servo ). There are  parameters like "running time" and "interval between frames" inside the messages necessary to position the servo. Same parameters for the servos should be in the command bytes sent by the ezb uart. How are they set  ?

this is not the Bluetooth plugin. The servo protocol is. Or Bluetooth. Either way, all servo transmission commands are bytes. Computers only use bytes.

the question again is those parameters have no description to what the values are. I figured out the servo position value through trial and error with you. That’s there were so many plugin versions.

as it stands, the other parameters are a mystery.  Until there’s an idea of what the other parameters are, there’s nothing more I can do