Thumbnail

UBTECH Alpha Servos UBT-12HC

by UBTech

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

Get Version 11 (updated 2/27/2020)

How to add the UBTECH Alpha Servos UBT-12HC robot skill

  1. Load the most recent release of ARC (Get ARC).
  2. Press the Project tab from the top menu bar in ARC.
  3. Press Add Robot Skill from the button ribbon bar in ARC.
  4. Choose the Servo category tab.
  5. Press the UBTECH Alpha Servos UBT-12HC icon to add the robot skill to your project.

Don't have a robot yet?

Follow the Getting Started Guide to build a robot and use the UBTECH Alpha Servos UBT-12HC robot skill.

How to use the UBTECH Alpha Servos UBT-12HC robot skill

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

Similar Skills

Auto Position (Gait)

Auto Position (Gait)

By Synthiam
Create frames and actions to animate the robot servos into...
Auto Release

Auto Release

By Synthiam
This skill automatically releases specified servos after a...
Continuous Servo

Continuous Servo

By Synthiam
Unlike a Standard Servo, a continuous servo has its...

ARC Pro

Upgrade to ARC Pro

Harnessing the power of ARC Pro, your robot can be more than just a simple automated machine.

Load More ...
#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
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.
Login to post a comment