Control the UBTECH Alpha Robot Digital Servos (UBT-12HC) with ARC
How to add the UBTECH Alpha Servos UBT-12HC robot skill
- Load the most recent release of ARC (Get ARC).
- Press the Project tab from the top menu bar in ARC.
- Press Add Robot Skill from the button ribbon bar in ARC.
- Choose the Servo category tab.
- 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
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.

I have : 1 =full counter clockwise (-90)
70 =center
140 =full clockwise (+90)
more than 140-145: servo stalls and releases (self protection)
So is movement range correct or not ?
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 ?
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 ...
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 ?
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.
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.
you wrote:
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...
This is in response to post 102
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.
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.
Yes i mentioned that before, but that's is correct is not wrong, based on the existent hacked information.
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.
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.
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.
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.
Can you take a screen snip ? It's a simple tool, I can't figure out your issue.
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:
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
Based on the above information from the same source:Code:
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:
EZB serial output:Code:
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.
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.
About your post 112 You're right.
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.
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
So do I. I'll try with 1. ( the checksum needs to be modified accordingly)
I think these values don't apply to alpha's servos.
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.
i'll test the new plug in.