UBTECH Alpha Servos UBT-12HC

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.