Our new robot friend is here for you, Workshop 88 colleague! This doc is to help you work with him. What amazing things will you teach him to do?
In late April 2020, members Tom and Christine made a ‘bulk purchase’ of three Scorbot ER-III 1990 vintage robot arms with controller boxes, and donated one to W88. The three were named Huey, Dewey, and Louie; Dewey now lives at W88. Below is some detail and history about this robot. The manual is here.
Here’s a nice picture of the motions the arm is capable of and their names.
How Scorbot’s creators think
The operational model of the original software controlling this robot is rather different from how we usually think of CNC machines today. We think of tool paths, defined by the gcode we send to the machine. The Scorbot view is a programmed series of steps. Programming consists of manually jogging (usually with the teaching pendant, which we don’t have) to a destination point, remembering/recording that point, then using it later with a command like “go to point 12”.
Both the old DOS-only Scorbase software and Engineering For Less’ Scorbot ERIII robot controller v0.1 have this world view.
The controller box
The black controller box allows, but does not particularly support this view (at least in our version). Its basic commands are like “move motor A +/-N encoder steps”, and “set motor A speed to S”. It allows multiple overlapping commands, which complete independently, but knows nothing of program steps.
Interaction with the controller box over the serial channel is either repeated polling to see when motor movement is done, or via an ‘interrupt’ model where the controller will send a character or two to the software when something interesting happens – like movement done or input or switch change.
The RESET button on the controller’s front panel would be called “E-STOP” on current systems. Use it freely when the arm isn’t doing what you want, especially if it jams into something (like itself!) and the motor stops.
A nice feature is 8 channels of input and 8 of output that can be read/controlled over the serial channel. You can hear the form-C relays on the first 4 output channels click and see LEDs for all 8. There are switches on two of the inputs; the other inputs just need a dry contact closure to ground. Dewey’s output channel 8 doesn’t seem to work.
A fat cable with a 50-pin connector is the only connection between the arm proper and the controller box. That cable carries all motor power and encoder information to/from the arm. Dewey’s connector is not solidly assembled, and the fragile wires are at risk unless it is handled very gently.
Six 12V DC geared motors drive the various moving parts of the robot. Unlike stepper motors, these are proper servos. The funny-shaped plastic box at the end of each motor houses the encoder, which counts how far the motor has turned (and thus what angle the joint moves through).
When you tell the motor to move, the error between where it is and its new target count tells the motor which way to move, and it moves until there is no more error. This also means if something pushes an arm hard enough to displace the motor from its target, the servo loop will detect that error and try to make the motor move back to its target count.
The minimalist check that the controller and arm are at least basically working is with both main and motor power on to press and hold the MOTOR TEST button on the lower left of the controller. Each motor in turn should move back and forth a little.
The serial connection from the computer is 9600 N/8/2 and uses only pins 2, 3, and ground. The cable between the DB25 on the back of the controller and a ‘normal’ DTE serial port or USB adapter on the PC controlling it must be a ‘crossover’ or ‘null modem’. There are no jumpers (at least in our controller) to change this. There is mention of cable wiring in the manual that shows 2 and 3 crossed. There’s a dedicated serial cable for the Scorbot wired correctly. It should remain with the robot.
The controller really does expect two stop bits. If you’re typing from a terminal, the delay between chars provides more than one extra stop bit, so typing at 9600 N/8/1 works fine. But if you’re trying to script something – have a computer send commands – the sender is likely to send chars back to back, with no extra delay. In that case you must set up for two stop bits.
A valuable troubleshooting feature is the LEDs above the serial connector on the back. A single character at 9600 makes a clearly visible flash. Main power must be on for the Rx LED (data from the PC) to flash. Motor power must also be on for the Tx LED to light, although only certain commands will cause that to happen.
The quick minimalist operational and comms check is to connect a terminal, and with main and motor power on type the single character ‘a’ (upper or lower) (no <cr> needed). If things are working, the controller should send back an ASCII ‘0’ (whether the arm is plugged in or not). If not, verify the Rx LED sees your keypress. If that fails, get a crossover. <Return> by itself does nothing – there is no help or menu stuff. The controller is extremely bare-bones.
The robot’s clever mechanical design – like that the Elbow adjusts to keep the forearm orientation constant when the Shoulder moves – will make conversion to a current machine view difficult. “I only told the Shoulder to change angle, but that Elbow joint changed too!”
Another implication of this is that say, Elbow angles, that are perfectly fine with some Shoulder positions are forbidden (will crash into something) for other Shoulder positions. Glad I don’t have to write the software to protect against that.
There are a couple of approaches to controlling the arm.
- Basic serial commands A terminal or script can send short ASCII commands over the serial link to the controller to be executed immediately. The syntax for these commands is documented in Appendix A, Writing Software for SCORBOT-ER III of the manual. This is the ‘assembly language’ of controlling the robot. Some of the gory details below were written from this point of view, and may be useful to someone doing this.
- Software programming movements to the controller The original DOS-only Scorbase software or the latter-day Scorbot ERIII robot controller v0.1 by EFL Windows GUI program are typical of this method. They take the original approach of manually jogging the robot to specific locations, ‘remembering’ those locations, and defining a programmed set of actions while moving among those places. This is probably the simplest, most approachable way to make the arm actually do something.
- Software/hardware turning the arm into a ‘normal’ CNC machine This most sophisticated approach uses some generic CNC platform like MachineKit with a custom written Hardware Abstraction Layer that knows details of this arm. Such layers exist, but are still under development. This splits into two hardware variants. One talks serial to the existing controller; the other talks to alternate custom hardware that completely replaces the old controller for better performance. This approach uses CAM software to generate toolpaths often sent via gcode to the platform. This most complex method can provide the best flexibility (and, with external hardware, best performance), at the cost of the most setup and development. As of 5/20, this is being investigated.
Motor moves, counts, and speeds
The basic move commands of course take a motor number, but also take a ‘distance’, or more properly an angle change, to move. That is specified in encoder counts. Each joint is different, and its maximum movement takes a different number of encoder pulses. Example: 2m-100 tells motor #2 (shoulder) to move in the minus direction by 100 encoder counts. It’s helpful to have an idea of the max counts a joint can go if you need to enter a move distance. See the table below.
The joint with the largest max count (the Base) moves about 3000 counts; the smallest (the Gripper) 250. A move of +/-10 is most always safe and visible.
To help know which direction a joint is going to move each has an informal arrow showing what the ‘positive’ direction is (and its motor #). For Pitch, positive is moving the gripper upwards. For Roll, positive is clockwise looking from the front.
Each motor’s speed (‘velocity’) can be controlled separately over a range of 1 (slowest) to 9 (fastest), with 0 being fastest overall. Example: 2v5 tells motor #2 to move at a medium speed.
The conical base is empty. (There is some small plastic tubing that was probably for some kind of pneumatics. The tubing also reappears at the gripper.) The #1 motor rotates the whole top part of the robot on this base.
The rubber stop bumper and home switch are visible looking up between the base and the arm’s bottom plate. The switch is obvious (not shown here). The stop is visible in this pic near what are probably the anti-backlash gears, which it bumps into to limit motion.
Despite references to it as a ‘limit’ switch, this switch is much more of a ‘home’ switch, and trips near the middle of the base rotation, not one end. The rubber bumper operates the switch, but can move smoothly past it. From ‘home’, the base can move about +1700 and -1400 counts.
Welcome to Scorbot “homing”
‘Homing’ is an interaction between control software and some sort of switch. Each of the Scorbot’s ‘home’ switches operates a little differently, and so does the control software. This doc is being written while using the EFL Robot Control software. We’ll comment on each joint’s homing.
The Base home switch is in the middle of its travel. While a homing cycle starts in the plus direction (CCW from above), the software is smart enough to recognize when the motor stops moving without having hit the switch, presumably from running the rubber end stop into some gears. After a short timeout, it reverses direction, finds the switch (from the ‘too far’ side), and finishes homing just as if it had found the switch during its initial pass. This allows homing from any starting position, and seems to work well.
Note that there is no automatic interlock between the motors and the switches. Even if a switch is near the end of travel, unless there’s software monitoring it, the motor will cruise on past it until it hits something (or reaches its target count).
The Shoulder (motor #2) homes moving in the minus direction (moving toward the double bumpers in the back). I (re)set the limit switch to just before the bumpers, so this one behaves like a traditional limit switch. Has range of ~+1250 from home. This is a simple case.
Motor #3 has range of as much as 2300 if you keep adjusting Pitch to keep the Gripper and its motor from running into stuff, which they do a lot. The fact that the Gripper’s orientation with respect to horizontal doesn’t change as the elbow moves means it’s easy for it to run into stuff.
The home switch can be set to trip in any position with just a 5/32″ Allen wrench. One approach is to use that flexibility to set the switch uniquely for each task setup. Based on how you start up, you can have the home cycle leave the joint in exactly the starting position you choose. The EFL software stars an Elbow home cycle moving in the plus direction, but offers a warning that it expects the switch to be closed before it starts.
Sadly, the encoder for the Elbow motor isn’t working. Troubleshooting has not begun.
Pitch and Roll
These two motions are intimately related by their mechanical design, and are different from the others in that they both require simultaneous operation of two motors (4 and 5). If the motors turn such that that belts go the same direction, you get a Pitch change. If opposite directions, Roll. Controlling the motors manually with ‘m’ commands, 4m50 and 5m-50 gives a Pitch change; 4m50 and 5m50 gives Roll. If only one motor runs, you get some weird combination of both that is unlikely to be useful.
For reasons currently unknown, motors 4 and 5 run at slightly different speeds. For the same number of encoder counts, motor 4 finishes first and a little later 5 catches up, but they do travel the same amount. This means that when either Pitch or Roll is requested, there’s a little of the other motion blended in, with a little opposite direction jump at the end. This is just a mechanical shortcoming of Dewey. Maybe one motor’s weaker? Maybe some bearings are stiff? Feel free to troubleshoot and fix this!
The ‘home’ switch for Pitch is unusual in that it’s wired Normally Closed, unlike the others which are NO. The software seems to know about this, and it doesn’t look like Dewey has been modified. The home search often but not always starts in the plus direction. When it does and it hits the switch, it behaves OK. Other times not. Between the ‘interesting’ parallel-arm design, and the fact that the Pitch limit switch is mounted on the arm after the Elbow, the home position of Pitch seems dependent on the current position of the Elbow. I don’t understand how it is expected to work.
There’s a hard rubber block clamped on the shaft that carries the Gripper that bumps up against a black machine screw on the left side. This is a Pitch end stop – both ways.
Here’s a pic of the Gripper in the max Pitch position. If you try to go any further, it forces motion of the elbow. I’ve seen this behavior, and don’t understand it.
You should try to remember this position and not exceed it.
From up against the stop in the plus direction and backed off by 10 counts, we can go -450 until just before hitting the stop the other way. Here’s a pic of the Gripper in the minimum Pitch position:
You should try to remember that position as well and never go beyond it. Maybe we should mark lines on the forearm parallel with those limits.
The ‘home’ switch for Roll (on the Gripper) works sensibly. As Roll is unlimited, you can always home Roll successfully and it will leave the gripper so its movement is parallel to the pitch axis. Homing starts in the minus direction. Unfortunately, the mismatch between motors 4 and 5 means if the search for home moves a long way, pitch is affected as well. Rolling 180° takes about 350 encoder counts.
The Gripper is controlled by motor 8. One motor wire was broken and stuffed together so it touched and worked, until it didn’t. I resoldered the wire and it should be fine.
Sniffing the EFL software serial comms to the robot with BusDog, it uses 8m-360 to open the Gripper and 8m360 to close it. Some manual experiments indicate that at least on Dewey, 8m[-]250 works the same.
If you close it on an object large enough that it can’t close all the way with a simple 8m360, the motor will stall and the controller will know the motor isn’t done, as its target count hasn’t been reached. The motor will still be powered. If you forcibly remove the object, the Gripper will move again until closed.
Apparently the appropriate protocol (again, from sniffing what the EFL software sends) is to poll (with an A command) until you get an 8 (or 0 for all done – unlikely), indicating the controller detected an error with motor 8 – that it didn’t get to its destination (within some timeout). At that point, if you issue an 8P command to stop the motor (and reset its target count) you might hear a small click, but if you remove the gripped object, the Gripper will not continue to close. This protocol is implemented in the EFL controller software.
A sniffer test in ‘W’/interrupt mode showed a delay of about 2 sec between issuing an 8m250 and receiving an ‘8’ indicating an error with motor 8 (didn’t reach target). An 8p or b fixed it and got a ‘0’ interrupt char. This gives an indication of the controller’s view of a timeout.
Comment on changing speed
It really seems like there’s some kind of delay before speed changes take effect. If I enter a speed change, and the very next command is a Move (like for the speed tests below for each joint), it will usually start at the old speed, then remember it’s supposed to have changed, and from that point on honor the new speed.
The speed regulation is not very consistent, as joints like the Shoulder and Elbow, which sometimes fight against gravity and sometimes are helped by it, change speed noticeably (as evidenced by audible gear whine pitch changes), and in the direction predicted by the gravity interaction.
Motor movement reference table
Motor safety – motors stuck on
Don’t know where this goes, but I just left a motor on and jammed against its stop until it got hot by not noticing it. Might have been nice to have a current meter on the supplies to spot stalled, silent motors.
Note that both the Elbow and Shoulder should be able to be moved easily slightly by hand. If they’re hard, some motor is locked on, and you should hit RESET (or type ‘b’). This is a general statement.
We’ve been very fortunate in that the encoders in Dewey all work. The one for the Elbow worked, then didn’t, but fiddling with the 50 pin fixed it. I sprayed some snake-oil contact cleaner on the connector.
Sad update: The Elbow encoder is not working as of 5/15/20. 😥
Each encoder has 4 wires: ground, LED power, and each of the two photo receptors. There are pry out inspection ports, with the photo transistors right under them. Can’t see light by eye, but a camera sees the IR from the LED going through the encoder blade gap and the photo transistor.
Sadly, Tom’s arm has had problems with at least one encoder. We’ve learned a fair amount from troubleshooting that, but it’s not directly relevant to Dewey, so no details here.
For future reference, what you see when you look at the end of the encoder is the motor shaft in the center, surrounded by the black plastic encoder hub. Both should be turning together.
Dewey came missing the belt for the #4 motor. Jim ordered a belt in 5/20 and started to install it. When he ran into a problem with a part he couldn’t get off a shaft, Scott provided a wonderful suggestion that made it possible to get the belt on past what looked like an impassible obstacle. It’s great to have a team!
The original Scorbase software can be downloaded from Intelitek. Aimed at students, it has multiple, increasingly complete levels. It only runs under DOS, though it has been run on a Win 10 64-bit machine with DOSBox.
If the arm is used with the controller, having it sit on top of the controller box often saves some table real estate. If the arm is extended very far forward, especially if it’s holding something, the whole thing might try to topple forward. To mitigate that, at least for modest loads, there’s a clamp arrangement at the back of the controller.
This robot is a Workshop88 resource, just waiting for you to come up with a great application and implement it. Please step up and make it shine!