Thumbnail

UBTECH Alpha Servos UBT-12HC

Control the UBTECH Alpha Robot Digital Servos (UBT-12HC) with ARC

+ How To Add This Control To Your Project (Click to Expand)
  1. Make sure you have the latest version of ARC installed.
  2. Select the Get button in this page to download the archive file.
  3. Double click the downloaded archive file to execute installer.
  4. The installer will add this control to ARC.
  5. Load ARC and press the Project -> Add Control button from the menu.
  6. Choose the Servo category tab.
  7. Press the UBTECH Alpha Servos UBT-12HC icon to add the control to your project.

Manual

Control the UBTECH Alpha Robot Digital Servos (UBT-12HC) with ARC. The servos must be powered appropriately, and connected to the EZ-B v4 or IoTiny with the respective port. Visit the Config menu of this plugin to view the port configuration.

The Virtual Ports (V0..V99) in ARC can be assigned to the UbTech servos.

UART Ports
- This plugin requires the RX signal wire of the servo be connected to TX of the selected UART or digital port (if Software UART is selected on IoTiny)

- Hardware UART is for the EZ-B v4 only. Do not use software UART on EZ-B v4. View the EZ-B v4 datasheet to identify the UART ports (0, 1, or 2). EZ-B v4 datasheet can be found here: http://www.ez-robot.com/Tutorials/Lesson/18

- Software UART should only be used with IoTiny

- Default baudrate of UBTECH servos is 115,200

Bind To Virtual Servos
- The configuration menu also provides an option to select the Virtual Ports, which correspond with the ID's of the UBTech servos. If the UBTECH servo ID #0 is connected, select V0. #1 = V1, #2 = V2, etc..

Additional Info
- Discussion on these servos is here: https://synthiam.com/Question/3932


User-inserted image



Custom Bit Settings
There are 3 bits that seem to not be understood for the protocol. Since UBTech does not release the protocol for their products, the community is working to better understand what the parameters are. The configuration menu of this plugin allows you to set hardcoded values for those bits. The bits are for 5, 6 & 7.

Custom servo Position Mapping
The UB Tech servos have their own position range, and we don't know what it is. So, the configuration menu allows you to specify the min and max positions for the range. This will be mapped to the ARC servo position range. Meaning, if you set the range in this plugin, it will be mapped to the range for all ARC servo controls.

Protocol Packet Code
Here's a copy and paste from the plugin code. This is how the packet is being assembled to be sent to each servo. The values specified by you in the configuration menu are b5, b6, b7, mapLow and mapHigh.

User-inserted image

#1  
Does someone know about UBTECH Alpha 1S robot and its possible use with EZB ? What kind of servos and servo protocols does it use ?
I can get it for a low price and  I would like to use it with EZB ,  my beloved controller.
PRO
Synthiam
#2   — Edited
Look at the description in the top of this message - there's instructions on how to connect and use the UBTech servos with the EZ-B and ARC:D
#3  
OK, DJ. No doubt you had an answer for any robot issue !
I have EZB V4, but never used UART communication, only usual PWM servo control. 
I'll probably ask for some support when I get the ubtech robot.
PRO
Synthiam
#4  
I don't have any experience with that robot - nor have i used the servos. There's a link in the description to a thread on this servo type, you can re-visit that thread and see if anyone there can help. I won't be able to assist any further than this:)
#5  
OK. There are  many  people working on that issue and information in that link.
#6   — Edited
Geez that robot looks fairly tall and fast in a youtube demo ,wondering if it could still be hacked to be even taller without effecting the center of Gravity (The arch enemy of all tall robots).
Oh wait no that's just a camera trick I saw,put the camera Low down and you can make any robot look Gigantic. I saw another video that showed JD in the background about the same height so it does look like there is a height barrier to getting a tall one at a reasonable price unless you design one for yourself that is.
#7   — Edited
Hi, robo rad, the exact height of alpha 1S is 398 mm (ubtech specs). servo speed and torque are similar to usual servos (0.198 s  x 60,  12 kg.cm at 8.5 V).
But it performs high speed and stability. What's the secret ? Probably the sophisticated design of the control system, taking in consideration  weights, inertia,etc. for that specific mechanical structure.
I made a 720mm tall robot , similar to JD, simply actuating powerful  servos (Hitec HS 805BB) as required, but it's much slower and unstable !
#8  
I am students from indonesia, i have read your command in forum" how to control UBTECH servo's 12 HC for Alpha 1s, can you help me show to control them, i need this to do my project, so that i can finish my bachelor education.

thank you for attention
PRO
Synthiam
#9   — Edited
Read the instructions above. They're quiet detailed:)
PRO
Synthiam
#10  
Let us know your success - the instructions above are quiet detailed
PRO
Belgium
#11  
leonardo46

the alpha 1s stability comes mostly from using metal brackets.
also he has no movelble head or hands.that makes the robot very solid.
there is a new alpha 1E out now .

#12  
I have alpha 1S and have been trying  to  hack it with EZB, but I had problems...
What's new with alpha 1E ?  New software  ? Same hardware ?
PRO
Belgium
#13  
he have ears now and have a sensor in the chest.
i know only what is in the video.he will have new software cause,
off his ears.
#17  
is there a UBTECH Alpha Servos UBT-12HC plugin that works on a windows 7 computer?
the latest version just give a plugin error.
#18   — Edited
The answer is no as Windows 7 is obsolete and not supported anymore by ez robot or Microsoft... Update (or buy) your computer to Windows 10...  FYI please don't double post...
#20  
I have been testing the plug-in with  ubtech alpha1S  and an old version of ezb and a PC with  win 7 .   
The results weren't good . Servos were weak and slow, and some didn't move at all.
I know win 7 is not recommended for ezb. Perhaps the plug-in might work with win 10 and/or  new versions of ezb.
I'd like to  know  if  DJ or someone else has had good results.
PRO
USA
#21  
Hi Richard R, 

I checked all your robots here out, great job.

I am learning many things here, and I know I just scratched the surface. I started recently from a thought I had one day and love to learn. I found Ez-Robot  on day, this is where it started.  DJ and his crew do make things "easy". lol

I haven't see you here in a while, I tried to get Luis Vazquez to visit once and a while also.

Anyway, to make a long story short, I appreciate all you guys and hope you all will keep on contributing.

thanks again,

EzAng
PRO
Synthiam
#22   — Edited
@Robot Junky, this plugin works perfectly with the latest ARC installation. Please ensure you're running the latest ARC to keep up to date with latest features and compatibility. According to your last log update, you're running a version of ARC that is 1 year old (Version: 2019.01.26.00). All you have to do is download and install the latest ARC to keep up to date. Please ensure you're always running the latest software, as we put a lot of effort to update the software with new features for your benefit.

User-inserted image
#23  
Hi DJ and other alpha 1S hackers !
I want to test again the plug in, but I need help from any alpha 1s hackers. I attach a photo of the native controller and connections.
I'd like to disconnect totally the controller to avoid damaging it, but I want to use its battery for servos and ezb. How have I to proceed ? 
There are  4 x 3-wire connectors  for 2 arms and 2 legs ,The serial servo control line is unique ? and 3 plugs with black-red plugs for power supply  (somewhere in the body there is a 7,4 V lithium  battery) .  
User-inserted image
PRO
Synthiam
#24  
1) Unplug the connectors 

2) remove the existing pcb 

3) make a new pcb from a breadboard with new connectors
#25  
Thanks DJ.
The four servo connectors are to be connected pin-to-pin to make a single serial control line for all servos  (driven by  ezb serial port at 3,3V ) and a 7,4 V line  for the servos and a common ground ?  What's the pinout ? like usual PWM servos ? (positive at center).
What about the three black/red wires . One must be the battery itself, and the others ?
PRO
Synthiam
#26  
I have never had a ubtech servo to test or use, so i can't tell you the wiring pinout. You can probably tell by looking at the existing pcb. You're right about these things..

1) all servos and the ezb require a common ground. This is because gnd is reference for the positive. Without reference, there's no way for each device to know what a voltage is

2) all signal (Serial) lines of the servos connect to the ez-b serial port

3) all servos are connected directly to the battery
#27  
Thank you again. Do you know who  tested the the plug in  with the robot ?
PRO
Synthiam
#28   — Edited
Think you'd have to look through this plugin description. I believe there is a link to the discussion on the plugin
#29  
Alpha hardware and its wires problems  now are solved.
I  found nobody in the thread and plug-in discussion who has actually tested the plug-in with the real robot.
If there is somebody I'd be pleased to hear  from him.
PRO
Synthiam
#30  
What issues do you experience? 

is there a benefit if I created a plugin that connects to the alpha one Bluetooth using its original pcb?
#31  
My idea is  to create new functions for the alpha , using ezbv4 .  I was able to understand the robot wiring, pinouts, etc.  and now I'm experimenting the plug-in, that  was written  knowing the servo protocol, but, to my knowledge,  nobody has tested it on the 16  robot servo bus  yet. If somebody  did ,  I'd like to know if his experience was successful.

Could you  create a plug-in to communicate with alpha, using  ezb program and bluetooth (alpha has it) , without any hardware modification ?
It would be great !
#32  
I'm experimenting the plug in. I gave power and connected all control pins together  to ezb serial port TX pin.
To my surprise the serial port , when connected to the 16 servos , doesn't  output  correct digital levels (high=3,3 V, low =1,5 V (!), seen with oscilloscope).  The load of the 16 servos is excessive. This way it will never work . Some buffer is needed.
PRO
Synthiam
#33  
Your tests are not using a common ground. All uart/serial of all devices on all the planet are compatible with their respective logic voltage. In this case, 3.3v
#34  
Dj,the common ground was there.
The serial signal from the ezb serial port swings between 3,3 V (high level) and about 0,3 V (low level) with nothing connected. This is a perfect signal.
But when you connect many (16) servo control lines to the serial port (of course with a common ground !) the load is excessive and the port can't sink enough current to force a low level on the bus. The low level can't go below  1,5 V. These servos are different from other servos I have used. The input impedance is  much lower. The original hardware was  designed for them.  I'm now testing  using a cmos buffer CD 4050 on the serial port .
PRO
Synthiam
#35   — Edited
Hmmm - that's a terrible design on ubtech's part. 

Try something for me... connect your PC to the alpha controller via Bluetooth and tell me if there is a COM port detected. I need to know the communication to the alpha, and if it's a COM port, i found a bluetooth protocol that's not detailed, but we can probably make it work. Then if you wanted to add a camera, you'd need to add an Iotiny on the back as well.

That not ideal, but UBTech servo design appears poorly implemented. From viewing pictures of their controller, it appears to have an STM32, which is what the EZ-B and IoTiny use. Do they have a buffer on their pcb?
#36  
Frames and actions and music (mp3) are programmed on the PC by a program similar to ezb, and then transferred to the robot, via USB cable, into a memory card. Bluetooth only activates the selected actions. For this I use an android tablet.
Can you anyway invent something in such context ?
PRO
Synthiam
#37  
Connect your PC to the alpha controller via Bluetooth and tell me if there is a COM port detected
#38  
For some reason the bluetooth  in the PC isn't working . It does not detect the robot.  I'll try to understand what happens and let you know.
About  how the original hardware drives the servos, remember that there are 4 separate connectors , that we supposed to be tied together in the pcb.
Perhaps  the controller uses 4 different ports , each controlling only  4 servos (not 16), so reducing the current of  each port. Or there might be some other chip for that. There are many unknown small chips on the rear side of the pcb....
#39  
Here are photos of the PC screen  after connecting alpha to  PC. There is a  COM4  port. The device is called a " bluetooth headset ".

User-inserted image
User-inserted image


 It's enough for you to make a great plug in ?
PRO
Belgium
#41  
leonardo46

any pics of your robot?
#42  
Mine is alpha 1S.  It's very similar to the one you posted in your  previous post in this same thread (alpha 1E).
PRO
Belgium
#43  
leonardo46
cool,i have an alpha 1s too.the metal frame fo the servo's is great.
#44  
The servos are very precise and fast. It moves well. To control them by ezb would be great !
PRO
Synthiam
#45  
Try controlling only ONE or TWO servos with this plugin (not the entire robot). Be confident that you're using the correct servo ID. Also be confident that you have the servo connected to the correct EZ-B UART port. Just get one servo working first.

I verified the plugin code against all internet examples. It must work. If it doesn't work, continue looking further into your wiring configuration.
#46  
you mean the old plug in, the one with ezb ? no update on that plug in ? What's the  correct  uart port ? in my previous tests I used the one with its specific plug (tx,rx,gnd,+). Are there other serial ports ? I saw a serial signal out of there on the oscilloscope, but it wasn't good when loaded by many servos. Has someone reported such problem ?  
To isolate single servos isn't easy for mechanical reasons. I can probably test a minimum group of 3 . No problem with identities , they are written on each servo.
I'll let you know.
PRO
Synthiam
#47   — Edited
The UART port is the port that you select in the control. Read the manual at the top of this page to identify what UART you've selected. There's a link in the manual of this plugin for the datasheet to find the UART ports. 

*Note: do not use a software UART port on the EZ-B v4 with this plugin. Software UART is for IoTiny only!
PRO
Synthiam
#48  
Have you tested this yet? Use the latest plugin and test this please
#49  
I haven't done yet. For this  I have to isolate some servo without damaging the alpha , and use the ezb from another robot.  This requres some time .
I'll send a post as soon as possible.
#50   — Edited
Hardware issues for ubtech servos.

1)The  description for this plug-in refers to dynamixel  servos, that have 4 wires, with separate rx and tx .
Ubtech servos, instead,   have 3 wires only. Their communication is bi-directional, but  half duplex .  So the  servo  sometimes will try to force high and low the  communication pin, that's connected to the tx pin  of ezb v4 , that's  an output and  can't  be driven high or low  by the wire.  Can this work correctly ?

2) I want to avoid damaging the alpha or ezb with these tests.  I risk to short circuit the 7,4 V power pin  with EZB's uart  pin  !
I'd need  the right  connector for the servo, but  I couldn't find one.  It's not a JST. Its pitch is 2 mm . I'm afraid it's a proprietary  connector from ubtech.
I heard about AX connectors . I'm verifying if they are available and suitable  for the purpose. Can you help ?

Software issue.
I see 3 software uarts in the  plug-in configuration menu.  But ezb v4 has only one. I guess I must select  uart # 0.
PRO
Synthiam
#51   — Edited
1) no, dynamixel and your servos have 3 wires. The description connects the signal wire together to RX and TX. It's documented above with a diagram. 

2) i can't help with your wiring

3) no, the ez-b v4 has 3 hardware uarts. It's documented above in the manual. You can click to view the datasheet of your ez-b v4
#52  
1)My doubt was if hardware problems might arise connecting  ezb's  uart  TX pin  to  ubtech's unique  pin , that can receive , but can also  send digital signals  to ezb  TX port , that obviously can't receive , but , when non transmitting , is always outputting its own digital level,  i.e. 3,3 V.
If this is not a problem , I'll connect the ubtech control pin to TX of  ezb's uart.  as I did in my previous tests.

2) I hoped you or someone else knew the type of connector used. I'll go on looking for it. In previous tests I was near to burn out everything because of  a non solid connection  to the servo !

3)Sorry, I was wrong. I intended hardware uarts, the ones to use with ezb v4. And wanted to know which one of the 3 to configure ( I guess #0).
#53   — Edited
Hi DJ, I 'm starting with the test. I'm here:
User-inserted image

Unfortunately this new plug-in doesn't output anything at the the  uart TX pin (oscilloscope).
Previous plug  ins , used in my previous tests, actually created   a  115,200 bps signal. What's new now ?
Note that it says "non connected to ezb". But  I connected a pwm servo to  a digital port and could move it. ezb was working ok.
#54   — Edited
i canceled  this post. previous is still valid.
PRO
Synthiam
#55   — Edited
The UART TX works fine. Please ensure you have read the manual for this plugin. I don't believe you have checked the appropriate options in the config for this plugin. If you're using ID 3, then V3 needs to be selected in the UBTech Alpha servo Plugin.

Check this manual description for a link to the datasheet of your EZ-B v4 controller. That datasheet will show you where the respective UART pins are.
#56   — Edited
I used the right pins, and set  uart 0 and V3 as required, but  I clicked in the small square only, not in  the blue button , so setting had no effect , even if saved.  I checked well  , and now it works. You're right, as always.
I'll connect more servos .  I had hardware problems in previous tests  increasing the number of servos connected to the TX pin. Digital levels weren't correct (low level =1,5 V).   I'll check all connections before. Connectors don't exist and  I don't want to cut the wires, Hard to solve !
PRO
Synthiam
#57  
The servos move correctly with this plugin?
#58  
It moves with this plug in, but I tested with one servo only . I'm arranging for more servos,
PRO
Synthiam
#59  
And for speed of movement is faster than you had said it was before?
#60  
It's difficult to compare plug in speed with ubtech actions I had seen.
I made a comparison with ubtech specs provided by  a member , somewhere in this discussion,
For a 180 no load  travel @8,5 V  it's rated  0,594 seconds. With auto movement control I measured about 1 second.
#61  
I have tested more servos. I tested 1, 2,   and 5 servos all together. All servos  moved well. 
However ,  with 5 servos  connected,   the low digital level on TX pin increased from 0,2 V to 0,8 V. When I connected 10 servos (both legs) it became 1,32 V as you can see here , and no servo moved any more.
User-inserted image

I already noted this fact in previous tests. Some hardware addition is needed (CMOS buffer/driver Cd 4050)
#62   — Edited
I added a CD 4050  chip , powered by +3,3V from EZB, and now all servos work . Low digital level , with 16 servos  connected,   is  0,16 V.
Note. Servos not specified  in ezb controls  are released. Is this normal ?
PRO
Synthiam
#63  
Yes, if a servo isn't specified it doesn't have a position. You can't expect them to have a position when the servos haven't been instructed to have a position. Things only do something when they're asked to do something. Otherwise, they don't do something.
#64   — Edited
OK, I understand. 
What about the hardware problem I have found (posts 61 and 62)?
Perhaps a future ezb might have some buffer inside to be able to drive many third party servos  on that line.
PRO
Synthiam
#65  
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.
#66   — Edited
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.
#67   — Edited
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.
PRO
Synthiam
#68   — Edited
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...

User-inserted image
#69   — Edited
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.
PRO
Synthiam
#70  
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
#71  
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  ?
PRO
Synthiam
#72   — Edited
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
#73  
Ok, DJ. no more about protocols , I know there isn't enough information about that.

But , please refer to the[u] first part of my post, i.e. :  Using "jump to " eveything works ok .
[/u]My question is : how to make servos ,while  executing an action, move as fast as  with "jump to " ? I couldn't get this , setting  delay, steps, speed  in many ways  in ezb . If this is possible, everything might work.
PRO
Synthiam
#74  
One of the protocol parameters must be some sort of timeout. I can’t make head or tails of it. Without knowing details of the protocol, there isn’t anything more I can do. We’ve been using random values in the protocol to see if the servos behave differently.
#75  
Ok. no more about protocols. Don't shoot anymore in the dark.
Follow another path. I found that , if the servos move at their full speed , the positions  are always correct and reliable. This overcomes the  time outs.
I could  move the servos very fast only using "jump to" in the AutoPosition window. I need to achieve this speed when executing an action.
Using usual ezb tools (delay, steps, speed) I couldn't have such high speed .  I don't know why , but you  surely can tell me how to do.
Perhaps we are near the solution. Trust me, i've designed  hardware and software of all kinds for over 50 years.
PRO
Synthiam
#76  
Without knowing what command to send to the servos, they will not respond correctly. The Auto Position send servo movements, which use the protocol. More information is required to understand the protocol because the parameters are not documented. Until there is additional information regarding the protocol, this is the last response i will have on this topic. Telling words stuff chair run red candle fire. Vacuum sofa pump water cupboard hat. The ran cold with bright near.

See, those words don't make any sense, right? That's how a protocol works. We're sending information that is causing the servo to behave the way it is behaving. The conversation has nothing to do with the Auto Position or any ARC servo controls. The only solution to have the servos react correctly is to know what commands to send them.
#77  
I think ubtech will never provide more information. The work done was  useless.    
But  i've still  to understand why with  "jump to " it works perfectly and with  "execute action"  it doesn't. Both  should send the same messages !...
If  you don't want to deal with this topic any more, this will remain a mistery for me.
PRO
Synthiam
#78   — Edited
The Jump To sends the frame servo positions as one instruction to each servo. 

An Action sends multiple servo positions over and over to accurately control the position during transition. 

the protocol uses to communicate with the servos has some undocumented parameters that must deal with some sort of movement timeout. Those unknown parameters are why the servos don’t respond well when receiving many movement instructions of an Action. 

Without knowing the parameters, it appears the servos somehow timeout or do something unpredictable when positions are sent rapidly. 

the only thing I can suggest as a trial that might work is to..
1) set the STEPS of every frame in an action to 10 or something 
2) set the DELAY of every frame in an action to 500ms or something lol 

it’ll move slow but that might give the servos enough time to figure themselves out.
#79   — Edited
I understand  you may be a little tired with this hopeless work , but i'm  happy to see you didn't give up with it.
So do i. I've done much work installing iotiny in the robot, and I'm still trying to work out something in this unknown environment.

I observed with an oscilloscope what happens at the uart port . The difference between jump and execute is as follows.

1) when one  jumps to a frame :    a single burst of about 15 ms is generated ( it contains about 170 bytes)
2) when one  executes an action : 2 bursts  of 15 ms are generated for each frame. They're spaced about 200 ms. 
This always happens, no matter how you set delay, steps and speed. 

1) QUESTION : EACH MESSAGE TO POSITION 16 SERVOS SHOULD BE  20 BYTES LONG. WHY DO YOU SEND SO MANY BYTES (170) ?
2) QUESTION : WHY  ,WHEN EXECUTING AN ACTION , 2 BURSTS, OF 170 BYTES EACH, ARE GENERATED FOR EACH FRAME? 
CAN YOU SEND, FOR ME TO STUDY, THE MESSAGES YOU SEND ?
#80  
I had no reply, as you said in your post #76.
I can't go on alone with these  experiments. I could send trial messages by a PC or microcontroller , but it would be a too hard work.
PRO
Canada
#81  
@leonardo46 

@DJ has limited internet access at the moment, but I wanted to ask you if you've tried what he suggested?

Modifying the action steps and delay may help by spacing the data out a bit.
#82   — Edited
Actions send a very large number of  bytes (about 170) , much more than what's  required for moving servos from a frame to the next one (20 bytes).
This always happens , no matter how you set delay and steps.  This causes uncertain positions for the servos.
If EZ-B could send 20 bytes for each frame transition , spaced , say, 100-200 mS or more, things  might perhaps work.
PRO
Synthiam
#83   — Edited
Look at the manual for the alpha Bluetooth servo protocol. I believe it’s 8 or 10 bytes to move a servo. Please do not type in all caps.
PRO
Synthiam
#84  
Ps, if you want to see the messages then connect to the ezb emulator. Set the emulation device (iotiny) and use your project.
#85   — Edited
I'm very ignorant about ezb products. I know and use ARC, but what's "ezb emulator" ? another  PC software (  where can I find  it ?) or a special function of ARC itself ?
PRO
USA
#86  

Quote:

I'm very ignorant about ezb products.
just pay attention to what is installed on the machine so you know what's in there:
User-inserted image

:)
#87  
I'm ignorant. What program is this ??? what "machine"  ???
PRO
USA
#88  
Are you serious ? 
Look your windows / Start menu / Synthiam Folder
PRO
USA
#89  

Quote:

...if you want to see the messages then connect to the ezb emulator. Set the emulation device (iotiny) and use your project.
PRO
USA
#90   — Edited
@DJ:
User-inserted image

@DJ:
I just got curious .... above you have the output of 3 servo positions 1, 91, 180 (ARC software servo degrees) based in the existent info:
https://alexsonea.com/2017/10/15/jimu-hacking-the-communication-protocol/

UBTech Servos rotate 180 degrees and they use 0 for the middle point, so they rotate -90 to 90, using a single byte they can't fit 360 degrees, but they left the door open to cover [-120 to -120] so for a 180 degrees the output must be:

Code:

-90 degrees servo /   1 degree ARC   = 120 - 90 = 30
 0 degrees servo / 91 degrees ARC  = 120 + 0 = 120
+90 degrees servo / 180 degrees ARC = 120 + 90 = 210

Only the middle point seems correct, the angles are stretch to an interval of -120/+120  i presume values < 30 or > 210 will be ignored.

*** edit ***
Check the post below
#91   — Edited
I' m serious, but ignorant in ezb's things. I looked at that folder, and have found it. I had  never  looked at that folder before. Thank you.
PRO
USA
#92   — Edited
@DJ,
A correction it seems the servos / software supports -120 / +120 
User-inserted image


So the plugin is mapping an interval of 1-180 to -120 to 120, is not stretching but is not correct either, the map should be between [1-240] to [-120 / +120]
PRO
USA
#93  
@Leonardo46:
this is the emulator (Emulating an EZB4 v2)
User-inserted image


this is ARC/EZ-Builder:
User-inserted image
#94   — Edited
@PTP.
I see you've done some work on ubtech servos. You mentioned  robot Jimu . Are you testing on all servos of  that robot or on a single servo ?
Are  the servos and protocol the same as Alpha 1S robot i'm testing with DJ'S plug-in ?
I found different results in my tests. Movement range for me is correct, but action execution is erratic.
PRO
USA
#95  

Quote:

I see you've done some work on ubtech servos.
 no work, i just got curious with this thread.

Quote:

 You mentioned robot Jimu
i took a few minutes crawling the thread up and down... DJ wrote:

Quote:

Discussion on these servos is here: https://synthiam.com/Question/3932
Post #27:
User-inserted image

So I follow the link and I post here. ASFAIK there is no public information regarding the Alpha 1's SERVO, one user contacted them and they mentioned the protocol is private. 
I believe DJ is using that information.

Quote:

Are the servos and protocol the same as Alpha 1S robot i'm testing with DJ'S plug-in ?
based in the above link,  I believe UBTECH Jimu robots uses the same UBTECH Alpha 1S servos or at least the same servo protocol.

To be honest I think is a waste of resources to do plugins for hacked toys without a public API.

I imagine DJ trying to get the best results and complaining about their implementation, but, their implementation is private is not their intention to share with third party and it works for them. 

Imagine someone trying to connect/hack an EZB controller without having information regarding the protocol or knowing the PCB, I would find a lot of design issues (because I'm guessing) and I don't have clue why it works that away. 

BUT on the other side I too like to hack and explore new stuff... so I understand DJ.
PRO
USA
#96  

Quote:

I found different results in my tests. Movement range for me is correct, but action execution is erratic.
So if you run this script:

Code:

Servo(V1, 1)
Sleep(2000)
Servo(V1, 91)
Sleep(2000)
Servo(V1, 180)
The servo moves 180 degrees correctly ?
#97  
Not exactly.
I have : 1 =full counter clockwise (-90)
            70 =center
            140 =full clockwise (+90)
more than 140-145: servo stalls and releases (self protection)
PRO
USA
#98  
but you wrote:

Quote:

Movement range for me is correct
So is movement range correct or not ?
#99  
for "correct" I intend I can  position the servo within its complete movement range 0 to 180, not necessarily inputting  numbers 0 to 180. 
This way it works.
The problem arises when executing fast and complex actions by EZB, that seems to send much more bytes than needed. I observed the byte stream with an oscilloscope. I'm trying to understand what ezb really outputs when performing actions.
That's why I need the ezb emulator, that I wasn't able to connect. I saw the images you sent, but I had no connection. Can you suggest why ?
PRO
USA
#100   — Edited

Quote:

for "correct" I intend I can position the servo within its complete movement range 0 to 180, not necessarily inputting numbers 0 to 180.
OK, So what you say is 1-180 does not translate to an interval -90 to 90 ?
And you worried with auto-position and complex moves ... ?

It's not my toy... but we are not discussing IDs or codes, we are talking degrees:  I would be worried for a 180 degrees servo 1 is not in the left side and 180 is not in the other extreme and 91 in the middle. 

It hurts my brain imagining rotational values with a side paper ...  

Quote:

That's why I need the ezb emulator, that I wasn't able to connect. I saw the images you sent, but I had no connection. Can you suggest why ?
You run the emulator you select listening, then you connect ARC to the localhost address. I presume you are running the emulator and the ARC in the same machine.
Also check:
1) if you don't have another software/service running on port 23. Port 23 is reserved for telnet protocol, is not common but sometimes people add extra windows features and one of them is the telnet server.
2) If you have an antivirus or a anti-malware check if they are not blocking requests to port 23, once again because that port 23 raises red flags.
3) Try to run EZ-B Emulator with elevated privileges some security conventions advert tcp ports below 1024 are reserved for services / kernel modules not for user apps.

I'm guessing, are you using Windows 7 ?
#101   — Edited
Alpha 1 Series PC communication protocol (3).pdf Alpha 1 Series Bluetooth communication protocol (3).pdf
Here is public information from ubtech, related to their bluetooth and PC protocols.
Did you know these documents ? I'd be pleased if you took a look to them, and see if you worked on the same documents,  and if you see there something useful for our tests.
I'll try your suggestions about connection, but tomorrow. Here it's time to go to bed,
Thanks for you collaboration.
PRO
USA
#102  
that's public I know
but that is not for the servo protocol, did you read the other thread ?
Another user mentioned a contact with UBTECH and they denied that info.
PRO
USA
#103   — Edited
I'm only here for a couple hours, but my assumptions are based on the existent information here and in the other thread.

you wrote:

Quote:

1) when one jumps to a frame : a single burst of about 15 ms is generated ( it contains about 170 bytes)
2) when one executes an action : 2 bursts of 15 ms are generated for each frame. They're spaced about 200 ms.
This always happens, no matter how you set delay, steps and speed.

1) QUESTION : EACH MESSAGE TO POSITION 16 SERVOS SHOULD BE 20 BYTES LONG. WHY DO YOU SEND SO MANY BYTES (170) ?
2) QUESTION : WHY ,WHEN EXECUTING AN ACTION , 2 BURSTS, OF 170 BYTES EACH, ARE GENERATED FOR EACH FRAME?
CAN YOU SEND, FOR ME TO STUDY, THE MESSAGES YOU SEND ?
I can't understand why you asked the above questions, each servo command message is 10 bytes. 
If you have a frame with 17 servos ARC will send 17 x 10 bytes = 170.

I don't see nothing wrong there, for me what is awkward is the servo range.

maybe i'm jumping the conclusions...
#104   — Edited
I worked  in the other thread too. Look at this  bluetooth protocol. There are messages for positioning one servo , and even to position  more servos with  a single message, and they should be the same  with  WiFi .
This is in response to post 102
PRO
USA
#105  

Quote:

I worked in the other thread too.
LOL, but you missed the url, the guy hacking the protocol because there is no public information, etc:)

Quote:

Look at this bluetooth protocol. There are messages for positioning one servo , and even to position more servos with a single message
Correct the Bluetooth protocol is documented allows positioning, reading the servos, broadcast a position to multiple servos, but that is THE BLUETOOTH PROTOCOL. Wait let me check if I'm the correct thread.... checking ... yes I'm looking to the plugin to drive the servos directly so that info does not apply.

 the Bluetooth protocol header starts with 0xFB, 0xBF and the command code 1 is an handshake, the servo serial protocol starts 0xFA 0xAF and the servo position command is 1. 

I have here the dynamixel serial protocol, maybe we can try ? Is also a serial servo protocol does it make sense to try ? No. 

You should try the EZB emulator maybe you can check the bytes sent per action, and double check if they match the number of servos.
#106  
response to post 103.
message length is variable. A message of 10 bytes is for positioning a single servo. 20 bytes is for positioning all 16 servos , giving all the angles.
But, indeed,  ezb sends much more than 10 or 20 bytes it sends about 170 ( I observed with an oscilloscope ).  this makes servos not to work well.

I must go to bed. I'd be happy to go on tomorrow.
PRO
USA
#107   — Edited

Quote:

20 bytes is for positioning all 16 servos , giving all the angles.
Are you discussing Bluetooth plugin or this (serial servo) plugin ? 20 bytes is possible but is a a bluetooth protocol message not a serial bus message.

Quote:

But, indeed, ezb sends much more than 10 or 20 bytes it sends about 170 ( I observed with an oscilloscope ).
Yes i mentioned that before, but that's is correct is not wrong, based on the existent hacked information.

Quote:

this makes servos not to work well.
I don't see how, do you have more info regarding the servo serial protocol ?

To summarize the only thing i see wrong is the servo range.

Please re-read my posts, you keep repeating the same thing based in different information.

Good luck with the emulator.
#108   — Edited

Quote:

Quote:
1) when one jumps to a frame : a single burst of about 15 ms is generated ( it contains about 170 bytes)
2) when one executes an action : 2 bursts of 15 ms are generated for each frame. They're spaced about 200 ms.
This always happens, no matter how you set delay, steps and speed.

1) QUESTION : EACH MESSAGE TO POSITION 16 SERVOS SHOULD BE 20 BYTES LONG. WHY DO YOU SEND SO MANY BYTES (170) ?
2) QUESTION : WHY ,WHEN EXECUTING AN ACTION , 2 BURSTS, OF 170 BYTES EACH, ARE GENERATED FOR EACH FRAME?
CAN YOU SEND, FOR ME TO STUDY, THE MESSAGES YOU SEND ?
I can't understand why you asked the above questions, each servo command message is 10 bytes.
If you have a frame with 17 servos ARC will send 17 x 10 bytes = 170.

I don't see nothing wrong there, for me what is awkward is the servo range.

maybe i'm jumping the conclusions...
i explain the  story of this complex misunderstanding around this matter.
Dj proposed a plug in to hack the robot using bluetooth, without any hardware modifications.  But I knew that ubtech  used bluetooth only to  send commands  to start actions ready for execution (pre programmed, sent to the robot via USB, and stored in its sd-card) , so  i told DJ :" you  can't move servos by bluetooth...".  But DJ replied "I can do that " and sent a plug in that actually did that.
When he made another  plug in, to move servos  by ezb serial port, i was certain he had used the same protocol as before . At that time  I didn't know about other protocols that other members might have.
#109   — Edited

Quote:

Quote
You run the emulator you select listening, then you connect ARC to the localhost address. I presume you are running the emulator and the ARC in the same machine.
Also check:
1) if you don't have another software/service running on port 23. Port 23 is reserved for telnet protocol, is not common but sometimes people add extra windows features and one of them is the telnet server.
2) If you have an antivirus or a anti-malware check if they are not blocking requests to port 23, once again because that port 23 raises red flags.
3) Try to run EZ-B Emulator with elevated privileges some security conventions advert tcp ports below 1024 are reserved for services / kernel modules not for user apps.

I'm guessing, are you using Windows 7 ?
Your suggestions didn't help. Connecting fails. I see in the debug area : name is valid, but requested data were not found . disconnected.
What have i to do ??
Yes, i use win7. I know it's not recommended, but at the moment i haven't a win 10 PC for the purpose. 
With ezb and pwm servos i never had problems.
#110   — Edited

Quote:

I don't see how, do you have more info regarding the servo serial protocol ?

To summarize the only thing i see wrong is the servo range.

Please re-read my posts, you keep repeating the same thing based in different information.

Good luck with the emulator.
i have no more info about protocols.
i always use the range 1-140. Exceeding this range stalls the servo.
When i say "actions don't work well" i mean, for example, for a repeating action, the positions aren't always the right ones. Often they're  wrong.
Dj and I guess that there may be a timing concern, i.e. the transition time must be coherent with the parameter "running time" that's in  the message.
PRO
USA
#111  

Quote:

Yes, i use win7. I know it's not recommended,
It's OK I still use windows 7. I post Windows 10 start menu screenshot, and you asked what kind of application... so I guessed you are not familiar with Windows 10.

Quote:

Your suggestions didn't help. Connecting fails. I see in the debug area : name is valid, but requested data were not found . disconnected.
Can you take a screen snip ? It's a simple tool, I can't figure out your issue.
PRO
USA
#112   — Edited

Quote:

Dj and I guess that there may be a timing concern, i.e. the transition time must be coherent with the parameter "running time" that's in the message.
I'll stop insisting it seems I'm hitting a wall, there is no public protocol for the servos.
I don't own the toy and I did the comments based on the existing information.
IF you or DJ have more information please share otherwise I think we are talking different things.

I'll summarize the relevant parts:

1)
https://alexsonea.com/2017/10/15/jimu-hacking-the-communication-protocol/
this is relevant part:

Quote:

For the time being here is a summary of the finds:

the communication is at 115,200bps
packages are send separately by servo; it doesn’t seem to be a bulk send instruction
the package has the following structure:
byte 1 and 2 = preamble = 0xFA 0xAF
byte 3 = servo ID
byte 4 = Command; for go to command we have = 0x01; we will try to find some other commands shortly
byte 5 8 = Command parameters; for command = 0x01 (go to) they are:
byte 5 = position = 120 + desired position in degrees
byte 6 = duration = duration in ms / 20
byte 7 = 0x00 (? we don’t know what this is yet)
byte 8 = 0x01 (? we don’t know what this is yet)

byte 9 = checksum = sum(byte 3 through 8) mod 256byte 7 = 0x00 (? we don’t know what this is yet)
byte 10 = closure = 0xED (from END?)
based on the above information there is no parameter "running time", maybe you based your guess on the bluetooth protocol, but, if the things don't work don't blame the UBTECH.

2)
https://alexsonea.com/2017/10/24/jimu-hacking-the-communication-protocol-2/
https://videos.files.wordpress.com/BkEIYNwW/pgz3tqwos4279eeqz27xda_dvd.mp4

Code:

go0 = bytearray.fromhex("FAAF05017814000193ED")
go45 = bytearray.fromhex("FAAF0501A5140001C0ED")
go90 = bytearray.fromhex("FAAF0501D2140001EDED")
Based on the above information from the same source:
0       = 79 hex = 120 dec
+45  = A5 hex = 165 dec
+90  = D2 hex = 210 dec

Switching to ARC's plugin: 

EZ-script to move the servos to the left 0, 45, 90, and right 0, -45, -90:

Code:

#ARC servo degrees range are: 1-180, middle point 90
#UBTECH servo degrees theoretically range are: -120 to +120, middle point: 0
#rotate left
servo(V5, 90)
servo(V5, (90+45))
servo(V5, (90+90))

#rotate right
servo(V5, 90)
servo(V5, (90-45))
servo(V5, (90-89))
EZB serial output:
User-inserted image


Quote:

byte 7 = 0x00 (? we don’t know what this is yet)
byte 8 = 0x01 (? we don’t know what this is yet)
byte #8:
I don't know why 10 is being sent when the safe (known) value is 01, without any other info I would stick with 1 to avoid unpredictable results.

byte #4 blue is the position and i believe the value is wrong:
for 3 positions tested in the video should be 120, 165, 210 and  the plugin is sending 119 (close), 179, 240

If I'm wrong please provide more information.
#113   — Edited
I must be blind ! I wrote  127.0.0.1.23   instead of  127.0.0.1:23  !...Now  the emulator works.  I can read the famous 160 bytes (i had guessed 170), I had seen  with the oscilloscope,
The messages are quite different from the bluetooth ones. I can't get any  inspiration from them. I'll change my mind.
I'll go on experimenting with the  incomplete protocol from Australian member Nicky777,  trying to make it work correctly with ezb. 
Thanks to PTP for his great help.
#114  
@PTP.
About your post 112

Quote:

based on the above information there is no parameter "running time", maybe you based your guess on the bluetooth protocol, but, if the things don't work don't blame the UBTECH.
You're right. 

Quote:

https://videos.files.wordpress.com/BkEIYNwW/pgz3tqwos4279eeqz27xda_dvd.mp4
This video shows a Jimu's servo, that appears to be quite different from alpha 1s ones. Related considerations about movement range probably don't apply to alpha's servos.

Quote:

Switching to ARC's plugin:

EZ-script to move the servos to the left 0, 45, 90, and right 0, -45, -90:
Code:
#ARC servo degrees range are: 1-180, middle point 90
#UBTECH servo degrees theoretically range are: -120 to +120, middle point: 0
#rotate left
servo(V5, 90)
servo(V5, (90+45))
servo(V5, (90+90))

#rotate right
servo(V5, 90)
servo(V5, (90-45))
servo(V5, (90-89))
I'm probably the unique member  who actually tested the plug-in  in an  alpha robot.
This script stalls the servo when 140 is exceded. Actual range is :  1=-90,70=center, 140=+90

Quote:

byte #8:
I don't know why 10 is being sent when the safe (known) value is 01, without any other info I would stick with 1 to avoid unpredictable results.
So do I. I'll try with 1. ( the checksum needs  to be modified accordingly)

Quote:

byte #4 blue is the position and i believe the value is wrong:
for 3 positions tested in the video should be 120, 165, 210 and the plugin is sending 119 (close), 179, 240

If I'm wrong please provide more information.
I think these values don't apply to alpha's servos.
PRO
Synthiam
#115   — Edited
This plugin has a change to allow the bits 5, 6 & 7 to be hardcode set in the config menu. Remember, byte positions start at 0, not 1. So when you discuss byte #8, you're really discussing byte #7.

You can also specify the servo range as well.

I no longer need to be involved in this plugin. All of the settings and configuration are available to you in the plugin.:) Have fun
#116  
I'm happy to see you went on working....
i'll test the new plug in.