UBTECH Alpha Servos UBT-12HC

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.

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

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.

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

OK. There are  many  people working on that issue and information in that link.

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.

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 !

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

Read the instructions above. They're quiet detailed

Let us know your success - the instructions above are quiet detailed

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 .

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 ?

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.

which sensor in the chest ?

its an ir sensor .

is there a plugin version that works on windows 7 ?

is there a UBTECH Alpha Servos UBT-12HC plugin that works on a windows 7 computer? the latest version just give a plugin error.

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...

Quote:

is there a plugin version that works on windows 7 ?

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.

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

@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.

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) .  

1. Unplug the connectors

2. remove the existing pcb

3. make a new pcb from a breadboard with new connectors

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 ?

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

Thank you again. Do you know who  tested the the plug in  with the robot ?

Think you'd have to look through this plugin description. I believe there is a link to the discussion on the plugin

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.

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?

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 !

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.

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

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 .

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?

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 ?

Connect your PC to the alpha controller via Bluetooth and tell me if there is a COM port detected

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....

Here are photos of the PC screen  after connecting alpha to  PC. There is a  COM4  port. The device is called a " bluetooth headset ".

It's enough for you to make a great plug in ?

I'll need you to do some testing. Please try this plugin and tell me if any of the servos move when you're connected to the bluetooth of the alpha. https://synthiam.com/Products/Controls/Third-Party-Robots/UBTech-Alpha-Bluetooth-Control-19020

Please continue this conversation in that plugin thread.

leonardo46

any pics of your robot?

Mine is alpha 1S.  It's very similar to the one you posted in your  previous post in this same thread (alpha 1E).

leonardo46 cool,i have an alpha 1s too.the metal frame fo the servo's is great.

The servos are very precise and fast. It moves well. To control them by ezb would be great !

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.

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.

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!

Have you tested this yet? Use the latest plugin and test this please

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.

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.

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

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).

Hi DJ, I 'm starting with the test. I'm here:

i canceled  this post. previous is still valid.

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.

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 !

The servos move correctly with this plugin?

It moves with this plug in, but I tested with one servo only . I'm arranging for more servos,

And for speed of movement is faster than you had said it was before?

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.

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.

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 ?

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

3. QUESTION : EACH MESSAGE TO POSITION 16 SERVOS SHOULD BE  20 BYTES LONG. WHY DO YOU SEND SO MANY BYTES (170) ?

4. 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 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.

@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.

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.

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.

Ps, if you want to see the messages then connect to the ezb emulator. Set the emulation device (iotiny) and use your project.

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 ?

Quote:

I'm very ignorant about ezb products.

:)

I'm ignorant. What program is this ??? what "machine"  ???

Are you serious ?  Look your windows / Start menu / Synthiam Folder

Quote:

...if you want to see the messages then connect to the ezb emulator. Set the emulation device (iotiny) and use your project.

@DJ:

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:

-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

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.

@DJ, A correction it seems the servos / software supports -120 / +120 

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]

@Leonardo46: this is the emulator (Emulating an EZB4 v2)

this is ARC/EZ-Builder:

@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.

Quote:

I see you've done some work on ubtech servos.

Quote:

 You mentioned robot Jimu

Quote:

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

Quote:

Are the servos and protocol the same as Alpha 1S robot i'm testing with DJ'S plug-in ?

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.

Quote:

I found different results in my tests. Movement range for me is correct, but action execution is erratic.

Servo(V1, 1)
Sleep(2000)
Servo(V1, 91)
Sleep(2000)
Servo(V1, 180)

The servo moves 180 degrees correctly ?

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)

but you wrote:

Quote:

Movement range for me is correct

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 ?

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.

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 ?

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 ?

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.

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.

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 don't see nothing wrong there, for me what is awkward is the servo range.

maybe i'm jumping the conclusions...

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

Quote:

I worked in the other thread too.

Quote:

Look at this bluetooth protocol. There are messages for positioning one servo , and even to position more servos with a single message

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.

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.

Quote:

20 bytes is for positioning all 16 servos , giving all the angles.

Quote:

But, indeed, ezb sends much more than 10 or 20 bytes it sends about 170 ( I observed with an oscilloscope ).

Quote:

this makes servos not to work well.

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.

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.

3. QUESTION : EACH MESSAGE TO POSITION 16 SERVOS SHOULD BE 20 BYTES LONG. WHY DO YOU SEND SO MANY BYTES (170) ?

4. 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...

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 ?

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.

Quote:

Yes, i use win7. I know it's not recommended,

Quote:

Your suggestions didn't help. Connecting fails. I see in the debug area : name is valid, but requested data were not found . disconnected.

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 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?)

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

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:

#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:

Quote:

byte 7 = 0x00 (? we don’t know what this is yet) byte 8 = 0x01 (? we don’t know what this is yet)

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 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.

@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.

Quote:

https://videos.files.wordpress.com/BkEIYNwW/pgz3tqwos4279eeqz27xda_dvd.mp4

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))

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.

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.

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

I'm happy to see you went on working.... i'll test the new plug in.