Control the UBTECH Alpha Robot Digital smart 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 smart 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.
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..
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.
when one jumps to a frame : a single burst of about 15 ms is generated ( it contains about 170 bytes)
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.
QUESTION : EACH MESSAGE TO POSITION 16 SERVOS SHOULD BE 20 BYTES LONG. WHY DO YOU SEND SO MANY BYTES (170) ?
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.