Talking to the device via serial port

uArm Swift (Pro) Troubleshooting
1

Hello everyone

I just received my uarm swift and wanted to do a quick demo. I had a quick look over the docs and it seemed to be based on simple ideas (Serial connection via cable or BT, G-code protocol).

However, until now, I have had minimal success in effectively talking to the device. Here is what I have done:

  1. Try to pair the UArm via onboard bluetooth FAIL. The uarm seems to only be responding to the BT dongle.

  2. Plugged the BT dongle in, installed FTDI drivers, succesfully recognised as serial port, started putty, connected to COM4 (this is the name the FTDI bridge assumes on my machine) at 115200. FAIL. I am getting a black window and no signs of comms.

  3. Unplugged the BT dongle, connected the uArm to the computer via the USB cable. It was recognised as COM5, started putty on COM5 at 115200, I am getting basic status messages: @1 @5 V1 (etc) but no joy when trying to send data to the uArm.

I am now trying to download the uArm studio, which really, I would not like to do since most of my work is about using the uArm via serial.

It is such a simple idea, just connect on the serial and start sending commands, I am not really sure where I am going wrong, any ideas?

All the best
AA

EDIT: Uarm Studio Stuck indefinitely in VC redist installation…

EDIT: Uarm Studio jumped to the “finish installation” screen after trying to restart. Installation finished. Cannot see the device whether via USB cable or BT dongle. Have tried restarting.

2

What message did you send by putty?

I suggest you to use the miniterm.py tool come from pyserial:

duke@duke-uf ~ $ miniterm.py -e /dev/ttyACM0 115200
--- Miniterm on /dev/ttyACM0  115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
00
echo:Filament settings: Disabled
echo:  M200 D1.75
echo:  M200 D0
@5 V1
start
echo:Marlin 1.1.0-RC7
echo: Last Updated: 2016-07-31 12:00 | Author: (none, default config)
Compiled: Jun 22 2017
echo: Free Memory: 3036  PlannerBufferBytes: 1232
echo:Hardcoded Default Settings Loaded
echo:Steps per unit:
echo:  M92 X320.00 Y320.00 Z320.00 E84.88
echo:Maximum feedrates (mm/s):
echo:  M203 X500.00 Y500.00 Z500.00 E25.00
echo:Maximum Acceleration (mm/s2):
echo:  M201 X2000 Y2000 Z2000 E10000
echo:Accelerations: P=printing, R=retract and T=travel
echo:  M204 P25.00 R25.00 T100.00
echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s),  Z=maximum Z jerk (mm/s),  E=maximum E jerk (mm/s)
echo:  M205 S0.00 T0.00 B20000 X1.00 Z1.00 E5.00
echo:Home offset (mm)
echo:  M206 X0.00 Y0.00 Z0.00
echo:PID settings:
echo:  M301 P22.20 I1.08 D114.00
echo:Filament settings: Disabled
echo:  M200 D1.75
echo:  M200 D0
@5 V1


P2201
ok VSwiftPro

--- exit ---
duke@duke-uf ~ $

Or try out our python library: GitHub - uArm-Developer/uArm-Python-SDK: New python library for Swift, Swift Pro

3

Duke, thank you very much for your reply, yes, indeed, that did the trick at least with cable operation. At the moment I cannot test the BT dongle option but I don’t see any reason why it should not work. I am so happy to see the arm responding to commands.

Can I please also ask if there is a document that describes the extents of the arm? That is, in polar (or cartesian) coordinates, what is the sphere (or cube) within which the arm can move? What are its full extents? Page 2 of http://download.ufactory.cc/docs/en/Swift-Quick-Start-Guide.pdf indicates the effective area within which the arm can move, does the code understand mm (or polar coords) in that frame of reference directly? I can put the arm in learning mode and read the full extents but that would not take into account its geometry.

Also,…and I am not proud about this :slight_smile: it is possible to jam the arm in impossible locations around the base. Would be nice to have the on board computer take the arm as close as possible to the requested position but not strain the arm.

All the best
AA

EDIT: What is the command to rotate the suction cup? I am trying G2202 N3 V90. No matter what V I am trying, the suction cup rotates in very very small increments. It takes all the slack of the pipe and then starts putting strain on the servo. It is impossible to make the suction cup rotate any faster. Is this something to do with the “time cycle of the feedback” or could it be something to do with the hardware? It can now move and grab things but it will not rotate them.

4

Hi @aanastasiou,

What is the command to rotate the suction cup? I am trying G2202 N3 V90. No matter what V I am trying, the suction cup rotates in very very small increments

You are using the correct Gcode command to move the 4th motor (I call it the wrist) via serial terminal. You could try prefixing with #25 to see if it returns ok or error code, or try giving it commands to go …V45 and then …V135 and see if it turns quickly. Hope this helps.

I have tried it myself and it is working okay. So far I have been able to move 4th motor from 0-180 degress and the motor rotation is not slow.

5

Hello @ebto

Thank you for your response. Good to know that this is the right command.

I cannot really determine if I am having some sort of hardware issue then… (@Duke, any ideas? )

Here is the arm, started up from default, rotated with G2202 N3 V45 and right after that sent the G2202 N3 V135 command. BTW, this is how the suction cup rotates anyway, it’s not these particular two angles:

https://goo.gl/photos/cdtRbfT6i7hBRH6G6

OK, so, someone looking at this might say “Something wrong with the servo”. But when you reset the arm, the suction cup returns to zero pretty quickly. Here it is:

https://goo.gl/photos/mVVARaPJJcwLXGCb7

In this video: I have started up the arm, rotated to G2202 N3 V45 and once that finished, simply disconnect from the arm. Here, it is also visible what I mention in another post, for some reason the arm jams itself in that position.

Anyway, the point here is that just before the arm resets itself, the suction cup rotates to its zero position pretty quickly.

I am not sure if this is a problem with the servo or the feedback from the servo or a matter of a parameter.

I am more inclined to fix this myself instead of shipping the arm back to uFactory. As long as I can get some help on what the key issue might be. First thing I would do would be to check if there is any constriction, anything that may have been over tightened. If that turns out to be ok I am going to remove the servo and check it on its own. If there are any problems with the servo itself, I could try replacing it. Not sure if it is a special grade servo or if one can be shipped from ufactory (?).

All the best
AA