(the bad focus annoyed me so I asked gemini to deblur, but I censored the hallucinated serial number)

If you’re excited to read more about ferrule crimpers, see this post.

[4] The confusing CAN documnt: e.g. ID(7) means device id register is at address 7 (and here it defaults to 001), not the ID is 7. Also — the English version of the CAN protocol document says “ByteDance” everywhere, when it just means “byte”. (ByteDance wrote Tiktok, in case the name sounds familiar). So it’s quite confusing to read… T__T

Learning to Read

anyway so what do all these mysterious numbers mean? let’s dive in

Deciphering cansend can0 001#280204 (Read command)

cansend can0 001#280204

Byte order

As per the docs, “all multi-byte register content transmissions use little-endian byte order , i.e., the low-order byte first and the high-order byte last”.

MIT Protocol (not MIT controller)

The MIT protocol is a spec for how bytes are laid out on the CAN bus, (and is separate from MIT mode/MIT controller, which is the torque impedance type of controls). The protocol runs over CAN bus and uses 11-bit frames and the message type is determined by length, i.e. 1 byte for ping and status, 3 for reads, 7 for writes, and 8 for commands.

Current Location

So we know that we want to send a 3 byte message.

We then come to the SIAR motor table.

We also see from the CAN Communication Control Protocol v2, under “Read Register”.

Thus taking

001#280204

We can parse that into the bytes, 28-02-04, then flip since we’re in little endian, so 0x0228, and then the final is 4.

Type of returned position

So we expect to read 4 bytes — in other words the a 32bit value for the position. In the provided example python file we see:

PRESENT_POSITION = 0x228
pos_raw_bytes = motor_comm.read_register(motor_id, PRESENT_POSITION, 4)
if pos_raw_bytes and len(pos_raw_bytes) == 4: 
    pos_raw = struct.unpack('<i', pos_raw_bytes)[0]

I was new to the whole struct situation. Referring to the python docs. https://docs.python.org/3/library/struct.html#format-strings
https://docs.python.org/3/library/struct.html#format-characters

so the < specifies little endian, then the lowercase i specifies a signed int.

Parsing the position

Again from the demo python code,

RAD_TO_SIGNAL = 2607.5946

This is equivalent to

(2^14)/(2*pi) = 16384 pulses / 2π radians ~= 2607

That is, an encoder that has 14-bit resolution across one revolution (2*pi). So we have 16384 pulses per revolution, and a single pulse is then about 0.02 degrees of revolution. (To verify: this is probably the position of the motor stator not of the output shaft (since there’s a planetary gearbox I think), then there’s a further translation to the position of the gripper jaws).

Deciphering cansend 001#00020101FFFFFF (Write command)

We can read from the table under the “hex” column

We know that the write command needs to be 7 bytes. It should go to 0x200 memory address. And the length is 1, and the value is 0 or 1.

So we have:
00 02 01 01 [Pad out to 7 bytes]

I had my handy word salad machine write out this diagram out 🙂

001#00020101FFFFFF
    └─┬┘ │└──┬───┘
      │  │   └── value 01 + FF padding
      │  └─ length 1
      └─ register addr 0x0200

Debugging

I didn’t mean this to come across so tutorial-like. The story of the post was meant to be a bit more … here’s the bugs I ran into.  A short list.

Bug: I could see from candump that I was sending out pings, but not getting responses

Debug: I hadn’t turned on power to the motor, only plugged in the USB CAM heh. classic.

Bug: The motor would accept pings, torque on, move successfully, then I’d send it a torque off command, and then when I tried to send pings or torque ons, it stopped responding.

Debug: Turned out, I usually turned the gripper off to reposition the motor (since I only cannot go to a + position, not a – position, and I hadn’t rezerod), and when I moved the gripper too fast by hand, presumably the back current going into the motor driver would cause a fault state in the CAN.

This was particularly annoying since I’d have to unplug and replug in the CAN and type in like 5 commands to get back to the same state, since I haven’t set up persistent naming of the device it would increment from ttyACM9 to ttyACM10 etc.

Bug: I knew zeroing command was correct since I’d used it before, but then the motor would not zero and show sudden movement.

Debug: If I looked more closely the motor was sending “00” in response, saying the write had not happened. If I read the docs this is because the register is in EEPROM (persists across reboot) and writes are only during torque off state).

Notes

Todo: Persistent Device Name

I should sleep, so please refer to:

https://damiao-motor.jia-xie.com/hardware-setup/can-set-up/#persistent-interface-name-fixed-device-name

Edit the file with the following:

# vi /etc/udev/rules.d/70-can-persistent.rules [5]

SUBSYSTEM=="net", ACTION=="add", KERNEL=="can*", ATTRS{serial}=="YOUR_SERIAL_HERE", NAME="can0

# Then reload
sudo udevadm control --reload-rules

The values can come from running dmesg | tail —

[ 2029.193842] usb 2-2: new full-speed USB device number 13 using xhci_hcd
[ 2029.322042] usb 2-2: New USB device found, idVendor=16d0, idProduct=117e, bcdDevice= 2.00
[ 2029.322060] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2029.322067] usb 2-2: Product: CANable2 b158aa7 github.com/normaldotcom/canable2.git
[ 2029.322072] usb 2-2: Manufacturer: Openlight Labs
[ 2029.322077] usb 2-2: SerialNumber: 207635634E45
[ 2029.326088] cdc_acm 2-2:1.0: ttyACM2: USB ACM device

Notes

[5] (70 denotes the rough order/priority for udev, the (l)inux device manager to process after the device is plugged in)

Reference: SocketCAN

https://wiki.st.com/stm32mpu/wiki/How_to_set_up_a_SocketCAN_interface

Reference: Gripper hardware design

Of note, maybe I want more grippers, there is actually an open-source version of a similar gripper mechanism, made to fit around a DaMiao branded gripper.
https://wiki.seeedstudio.com/dm_gripper/

next steps

zzz next steps: actually mounting this the UR5, which requires some 3d printing and some cabling.

the end, but i just remembered the  other update:

zzzz.

i was supposed to make a cool robot demo with software skills, but i’m still stuck in hardware land right now. but i’m having a lot of fun figuring things out. i find it easy to vortex people the people around me into enthusiasm about real life robots since well, they’re a bunch of roboticists too — don’t quite have the same with software / deep learning yet. but yea!

tld;r robotsssssssszzzzzzzz.

fin.