Control the UBTECH Alpha Robot Digital Servos (UBT-12HC) with ARC
+ How To Add This Control To Your Project (Click to Expand)
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
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 can get it for a low price and I would like to use it with EZB , my beloved controller.
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.
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.
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 !
thank you for attention
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 .
What's new with alpha 1E ? New software ? Same hardware ?
i know only what is in the video.he will have new software cause,
off his ears.
ubtech.com
the latest version just give a plugin error.
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.
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
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) .
2) remove the existing pcb
3) make a new pcb from a breadboard with new connectors
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 ?
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
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.
is there a benefit if I created a plugin that connects to the alpha one Bluetooth using its original pcb?
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 !
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.
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 .
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?
Can you anyway invent something in such context ?
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....
It's enough for you to make a great plug in ?
Please continue this conversation in that plugin thread.
any pics of your robot?
cool,i have an alpha 1s too.the metal frame fo the servo's is great.
I verified the plugin code against all internet examples. It must work. If it doesn't work, continue looking further into your wiring configuration.
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.
*Note: do not use a software UART port on the EZ-B v4 with this plugin. Software UART is for IoTiny only!
I'll send a post as soon as possible.
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.
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
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).
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.
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'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 !
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.
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 already noted this fact in previous tests. Some hardware addition is needed (CMOS buffer/driver Cd 4050)
Note. Servos not specified in ezb controls are released. Is this normal ?
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 makes software, called ARC.
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.
Iotiny is very small , perfect for alpha robot ! This option is needed.
Please use the config screen to adjust settings...
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.
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 ?
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
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.
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.
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.
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.
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.
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 ?
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.
@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.
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 your windows / Start menu / Synthiam Folder
@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:
*** edit ***
Check the post below
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]
this is the emulator (Emulating an EZB4 v2)
this is ARC/EZ-Builder:
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.
i took a few minutes crawling the thread up and down... DJ wrote:
Post #27:
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.
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.
Code:
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
Code:
go0 = bytearray.fromhex("FAAF05017814000193ED")go45 = bytearray.fromhex("FAAF0501A5140001C0ED")
go90 = bytearray.fromhex("FAAF0501D2140001EDED")
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:
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 112You'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.