An internet-connected killbot

Continuing the discussion from Scorbot-ER VII Robot Arm:

To recap the extremely sporadic efforts of getting our industrial robot arm working:

  • @funvill brought it in via friends as a donation to VHS, no strings attached (woo)
  • We have a manual! Digital copy in the linked thread, physical copy next to the control box
  • It got turned into the High-Five Bot, the official door greeter of VHS

I found a serial connection in the driver, desoldered the connector, and spliced in a proper DB9 serial cable. Then it worked fine with a USB-Serial dongle. Problem is, I did this in January and I don’t remember the settings!

The factory interface a pretty simple command prompt, poorly documented in the manual. “HOME ALL” seems to work, and by that I mean it causes the robot arm to repeatedly slam itself against the table and scare the hell out of everyone in the room.

So I was back at it yesterday, with two goals: Figure out the limit switches, and connect it to the internet. I failed at both, but here’s where I got.

To start with, this is what the controller looks like inside, in all its 80s glory.

Despite the appearance from the outside, this isn’t a computer in the modern sense of the word at all. You can see the main board on the bottom, all through hole parts, with a huge 6801 microcontroller up in the top right. The majority of the space is taken up by the beefy power supplies in the top, and you can see the expansion cards for each of the robot arm axis with the 1988 copyright year.

The first step was to find a 5v power rail. Using a sophisticated technique I developed - Reading the label - I was able to find the 5v wires going into the main board from the main power supply.

From there I was able to buzz out the proper pin on one of those unused board mount connectors on the bottom.

And then mount a Raspberry Pi. @Logan_Buchy and @Lukeo I owe you guys one now, I’ll bring it in as soon as possible!

At this point, the RasPi boots up along with the controller, and if you plug an ethernet cable into it, it registers as (dunno why) and the credentials are root / dietpi

The serial dongle is at ttyAMA0 I think, and I was trying to get it to work with Minicom, although no luck. The problem could be with my original hacky serial cable fix, using a different dongle, or using the Raspberry Pi. I will have to investigate further!

I also didn’t even look at the limit switches.

And that’s where we’re at.

As with any VHS group project, feel free to hack on it and add to this log. I’m not happy until we can reliably get it playing the knife game.


Its called wocket because my theme of naming computers that week was Dr. Seuss.

Great writeup BTW, documentation is good.


Needs more lasers! Maybe a simple one to start with, and then we can mount an industrial one for the knife game?

I tossed two usb-to-serial adapters into the case.

1 Like

Thanks, dude!

Works, using a different USB dongle provided by @toma

After SSHing in, type minicom --device /dev/ttyUSB0 and then help to see what’s up.


Because I expect this RasPi to be turned on and off nastily directly at the power switch a whole lot, does anybody have experience with locking the SD cards of these things to prevent corruption?

There’s a boot script at /DietPi/dietpi/boot that I’m considering adding the above command to, and then locking everything down. That’ll allow you to SSH directly into the controller’s terminal, without dealing with any of the Linuxy stuff.


Nice work! I’ve been enjoying reading about the progress.

AFAIK the read-only switch on the SD card is advisory only, so it basically does nothing. To prevent corruption you have to plead with the system to not write anything to the SD card (or at least not very frequently).

I used to remount the filesystems read-only with Raspbian, but honestly since switching to DietPi for these sorts of things, I just don’t really worry about it anymore. So far it hasn’t bit me. DietPi has a ramdisk log thingy, so make sure that’s enabled. It remounts /var/log as a ramdisk thus making it ephemeral, which is fine.

Great idea. If you do that and disable most of the unneeded services, the risk of corruption is probably really really low. Maybe take an image of the card just in case.

1 Like

Yup! Tons. The thing about SD cards is they already have their own flash translation layer (FTL) built into the microcontroller’s firmware. So corruption at the flash layer isn’t something you need to worry about.

However it still is possible to corrupt the file system residing on the block layer. A modern journaled file system like ext4 is very resilient to hard power down of the device - trust me, I spent a good few months beating the crap out of all the SD cards on the market (many are shockingly bad). Just make sure journaling is actually on (it is by default on ext4).

At a low level this is true. The switch isn’t electrically connected to anything, it’s supposed to trigger a switch inside the slot, and the driver or SD controller IC should suppress any writes. I’d expect the Pi’s Linux drivers to be properly behaved when encountering a read-only SD card, but the only way to know is to test it.

You need an OS designed to run from read-only storage for that to actually “work” though…I’m not familiar with any designed for this purpose that work on Pi other than OpenWRT - which might be a very viable option.

Love this project. I guess G-code would be the “modern” way to control such a robot?

One of the ways, I think you can often just use a pendant to train them.

On a more DIY setup, you can set up custom kinematics in LinuxCNC, basically you just have to tell it the mathematics of each “joint” (motor), and how they interact with the Cartesian coordinates of the end effector. Overview here:

Bit of a pain to set up (especially if there isn’t already a kinematics module for your setup) but really cool when its working. You get to treat the machine the same as a gantry mill.

1 Like

So we don’t have a pendant. The manual has a large section devoted to it, but we don’t have one.

I don’t think that’s a bad thing, they’re usually used in industrial settings for a trained robot arm wrangler to teach it a simple task that it will be repeating on an assembly line.

That doesn’t really apply to us, and most of us can do some form of programming. I did a bit of research yesterday, so I can talk a little more about that.

Our controller uses “ACL”, or Advanced Control Language. The commands work in the terminal, but they are not represented in the help menu.

For example, you can type show din to display all of the digital inputs, which is a controller command, and shown in the help menu. It will usually return 16 zeros.
After you type lson though, an ACL command and not in the help menu, two of those bits flipped on.

Exciting stuff! Presumably those are supposed to be limit switches, but in our brief test, @Shane and I weren’t able to make any more bits (including those) change.

Here is some more reading on our particular model:

There should also be some dedicated ACL reference manuals that I haven’t looked for yet.

I believe the controller also has a kinematics solver built in. Haven’t looked at it in detail, yet.


ACL reference guide I found…