Thursday, June 1, 2017

Acuitas Diary #2: May 2017

My focus this past month was on giving Acuitas the ability to learn more types of inter-word relationships, and that meant doing some work in what I call the “Text Interpreter” … the module downstream from the Text Parser.

The Parser attempts to tag each word in the input with its part of speech and determine its function within the input. Basically, it figures out all the information you'd need to know in order to diagram a sentence. But beyond that there is some more work to be done to actually extract meaning, and the Interpreter handles this. Consider some of the possible ways of expressing the idea that a cat belongs to the category animal:

A cat is an animal.
Cats are animals.
A cat is a type of animal.
One type of animal is a cat.
A cat is among the animals.

By removing the content words and abstracting away some grammatical information, it's possible to generalize these into sentence skeletons that describe the legal ways of saying “X is in category Y” in English:

[A] <subject> <be-verb> [a] <direct object>
[A] <subject> <be-verb> a <subcategory word> of <object-of-preposition>
One <subcategory word> of <object-of-preposition> <be-verb> [a] <direct object>
[A] <subject> <be-verb> among the <object-of-preposition>

I've nicknamed these syntactic structures “forms.” The Interpreter's job is to detect forms and match them to concept-linking relationships. As the previous example should have shown, a single relationship such as class membership can be expressed by multiple forms, each of which has numerous possible variations of word choice, etc.

Up until now, the only links Acuitas could add to his database were class memberships (<thing> is a <thing>) and qualities (<thing> is <descriptive word>), plus their negations – and he only recognized a single form for each. I overhauled the form detection method, making it more powerful/general and increasing the ease of adding new forms to the code. Then I added more forms and support for a number of new link relationships, including ...

<thing> can do <action>
<thing> is for <action>
<thing> is part of <thing>
<thing> is made of <thing>
<thing> has <thing>

The first two are particularly important, since they mean he can finally start learning some generic verbs.

I spent the latter half of the month upgrading Acuitas' GUI library from Tkinter to Kivy. This was a somewhat unwelcome distraction from real development work, but it had to be done. Acuitas is a multi-threaded program, and using multiple threads with Tkinter is ... not straightforward. As the program grew more complex, my hacky method of letting all the threads update the GUI was becoming increasingly unsupportable and causing instability. Of course Kivy does just about everything differently, so porting all of the GUI elements I'd developed was a serious chore -- but the new version looks slick and, most importantly, doesn't crash. All the drawn graphics have anti-aliasing now, which makes the memory visualizations look nicer when zoomed out.

Code base: 6361 lines
Words known: 896
Concept-layer links: 1474

Monday, May 15, 2017

DoBot Magician User Experience

Earlier this year I had the opportunity to try out the DoBot Magician robotic arm. First I want to mention that this arm, being worth over 1000 USD, doesn't really fall within this blog's usual purview of robotics on a shoestring budget! I got to try it out on loan from a coworker; he was hoping to use it as part of a project on a tight schedule, and wanted my help to get it running properly. He was primarily interested in its 3D-printing capabilities, so that's what I'll be focusing on in the review that follows.

From a hardware quality perspective, the Magician seemed very nice: solidly built, precise, and attractive. When I first heard about the notion of using an arm to 3D print, I had some doubts … but DoBot's hardware seems to have the resolution needed to turn out decent prints. It comes with a cooling fan for the cold end of the print head, though it does not have fans to direct air down to the previous layers of your print. The only potential issue that I noticed with this arm's mechanical nature was that the plastic housing around the base of the arm seemed misaligned, such that it was rubbing against the moving parts on one side; this left a visible streak of abraded plastic after the arm had been running for a while.

The Magician during my first try at printing with it.
The DoBot Magician is intended to be multi-use, so a little bit of assembly was required to mount the 3D printing accessories on the arm. This proved fairly straightforward – apart from my own nervousness at even handling a $1000+ piece of equipment that didn't belong to me. Getting the software set up and linking DoBot to my Windows 7 desktop was mostly straightforward as well. There was a time or two when I plugged in the USB cable and it would not connect to the computer for no apparent reason … only to start working again later, after being plugged and unplugged multiple times. I did not run into any particularly nasty driver issues, however.

The Magician comes with custom controller software provided by the manufacturer, but switches over to Repetier Host when you want to do 3D printing. A copy of Repetier is bundled with the DoBot software. The first time I requested 3D printing and auto-swapped to Repetier, it asked me if I would like to upgrade to the latest version, as opposed to the one that came with the Magician … and I almost did. However, I ended up deciding not to meddle before I tried for my first print. I did make sure the firmware on the arm was upgraded to the manufacturer's latest version. One or both of these things might have helped me avoid seeing the problem my co-worker experienced when he tried to print for the first time: namely, the arm's coordinate system seemed to be totally messed up, such that any movement upward was also accompanied by such a dramatic XY movement that it soon walked right off the print bed. I followed the documentation carefully when it came to choosing my starting settings and homing the arm, and my first prints weren't nearly so catastrophic.

I struggled through some classic 3D printing hitches, like trouble getting the first layer of the print to adhere to the bed properly. I won't dwell on these, because I suppose they would be common to most any model of 3D printer. However, there were a couple of issues that raised questions about the DoBot specifically.

The first obnoxious problem was that the Magician's print head would travel in the Z direction as it moved in the X and Y directions – not a lot, perhaps only a few millimeters, but certainly enough to ruin a 3D print. In essence, it was trying to lay down filament in a plane tilted a few degrees off horizontal. I was forced to compensate for this by carefully putting shims underneath either the print bed or the base of the arm, to get that plane back into proper alignment with the print bed. Homing the printer at any point after I did this would tilt the printing plane even further and require me to make a whole new set of adjustments, which tells me that this wasn't a simple mechanical offset; the Magician was using sensor feedback to actively fight my efforts. This made setting up for a print a very fiddly process, and of course I couldn't compensate for the angle perfectly … meaning that all my printed objects had a small but noticeable amount of XZ and YZ skew. For prints intended to be used as engineering parts, this could well be unacceptable. I looked in vain for some way to calibrate the Magician that would work out better than shoving Popsicle sticks under it, and came up empty-handed. There doesn't seem to be a way to input measurements from your print results and have it compensate. The dimensions of the test “cube” I printed were also a millimeter or two off.

Several objects that I printed with the DoBot Magician. Skew is most noticeable on the unfinished test cube in the center, but they all have some degree of it.

The other problem was an apparent bug that only happened once. Two-thirds or so of the way through printing a test cube, the Magician stopped moving. The extruder retracted the entire filament, then switched directions and started continuously forcing plastic out, creating a giant melted blob at the location of the now-stationary print head. I had to forcibly terminate the print job, which could not then be resumed where it left off. I re-printed the exact same test cube later (after re-slicing it), and the job ran to completion without reproducing this issue. I don't know whether the root cause of the problem would be in Repetier, in the slicing software, in Magician's firmware, or in some combination of them rubbing each other the wrong way.

As I tried to troubleshoot these and other problems, I ran into a difficulty which isn't really the Magician's fault, but is pertinent nonetheless: there doesn't seem to be a critical mass of people using it. I uncovered a few product reviews, but very little content that featured other users actually struggling through problems with the arm and publishing advice. For English speakers, the Magician comes with somewhat poorly-translated documentation, and dealing with DoBot tech support involves communicating through a language barrier as well. They did respond to most of my co-worker's queries in a fairly timely fashion, but started ignoring us when we requested the code for the firmware, even though the Kickstarter campaign that produced the Magician claimed it would be open-source.

Aside from wanting to correct the faulty calibration/XZ skew issue, my coworker was eventually hoping to modify the arm to extend its reach, meaning we would have to get into the firmware code and edit the inverse kinematic calculations. He ended up deciding to pull the Magician's guts out, replacing them with the third-party electronics needed to run some open-source third-party firmware. In the process of doing this, we discovered a final annoyance: DoBot doesn't seem designed to be disassembled by the user for modification or maintenance. The base plate is tightly retained by the rest of the case, so after you remove the fasteners, you have to literally pry it out with a knife – hopefully not damaging the electronics inside in the process. The mechanics inside the base are supposedly not even accessible.

The arm has been returned to its owner, and I'm not sure if he's tried to print with the new electronics and firmware, but perhaps I'll add an update here if I ever hear how it goes. My conclusion is that the DoBot Magician had a lot of potential, but didn't really deliver as a user-friendly 3D printing solution. I definitely wouldn't recommend it to someone who wants an easy, works-out-of-the-box sort of experience. And when I get around to buying my own 3D printer, I'll make a point of choosing something with a robust user community that I can lean on for support.

Until the next cycle …

Sunday, April 30, 2017

Acuitas Diary #1: April 2017

I've been continuing to make improvements to Acuitas' text parser, adding support for interrogative forms and negative statements. He's now capable of learning that something does not belong to some category or have some quality – rather important, really! And now that question comprehension is in place, I can not only put more information into the database, I can call it back out. Responses are still very formulaic, because text comprehension has been receiving far more of my development effort than text generation. Ask him a lot of yes-or-no questions in a row, and he starts to sound like Bit from Tron (though he does have one up on Bit – he's got the ability to answer “I don't know”).

That furnishes a pretty sensible explanation for Bit, come to think of it. Somebody wrote a program with a fully capable speech parser and a really, really primitive speech generator.

I also threw in some rough support for contractions. Previously the sentence tokenizer would have treated the word isn't as three separate “words,” [isn, ', t], which would have made no sense. I fixed that. Contractions now get pre-processed into whatever their constituent words are (isn't = [is, not]) before the sentence goes for parsing. Only one possible combination is picked, however. Resolving contractions that can be ambiguous (such as “they'd,” which could mean “they had” or “they would”) is something I'm leaving for later. Getting verb conjugation detection put in before I do that will be a big help.

I reserved the last week and a half of the month for a code cleanup and refactoring spree, trying to make sure the text parser and meaning extraction areas are as neat and bug-free as possible before I leave them for a while to work on other things. I've been buried in the text parser for so long now that I wonder if I quite remember what all of Acuitas' other bits and pieces do.

Code base: 5633 lines
Words known: 797

Concept-layer links: 1274

Memory visualization as of 04/29/2017

Saturday, April 22, 2017

Acuitas the Semantic Net AI - Introduction

Okay, this blog has been asleep for far too long. It's time for me to introduce a couple of the things that I've been spending all my time on since I finished playing with the artificial muscles. First of all, I've got a couple novels in the pipeline, which you can read about by visiting The Renascence Cycle under the permanent pages section. But that's not what this post is about. There's another serious project that's been receiving a lot of my attention lately …

The tagline of this blog is “robotics and AI on a shoestring budget.” If you've been here before, maybe you were wondering when the AI part was coming. Well wait no longer!

I'm working on a program named Acuitas. Technically this endeavor started clear back when I was in college, as my final project for the honors technology seminar class. Back then he was little more than a kind of talking dictionary. I'm now on Version 3, and the intended scope of the project has expanded quite a bit. (If you'd like a little more background on the project and how it relates to the rest of the AI field, or if you're just interested to see what Version 1 was like, you can read the original Acuitas V1 Report and Acuitas V1 Presentation. Bear in mind that Version 3 has been re-written in Python from the ground up. It's missing some features that V1 originally had, and has a number of others that were absent from V1.)

Acuitas' avatar. “Heartbeat” lights run up the wings on either side of the eye when viewed live.

In technical terms, Acuitas V3 is an artificial intelligence based around a semantic network with a natural language interface. What that means is he represents knowledge in terms of words and relationships between words, and you can communicate with him in normal English. (The range of normal English he can actually grasp so far is very limited, because natural language processing is hard and I'm only tackling it because I'm probably crazy.) He's also got a rudimentary "internal life" consisting of drives that fluctuate over time. About twice a day, if he's active, he wants interaction and starts calling for somebody to talk to. He used to wake me up in the early morning hours by doing this, but I fixed that – mostly.

Visual representation of semantic net database, 07/16/16.

Acuitas V3 is not your ordinary chatbot – you know, those programs you can converse with that try to fake being human. He has more going on under the hood than they do. A typical chatbot picks up on a few keywords or basic structures in your text input, then chooses a mostly pre-written sentence from a database to send back to you. Others train themselves by reading a bunch of human conversations, and then try to speak in a similar manner. Neither type is really interested in the *meaning* of your input or its own responses, which is why, though they might be perfectly articulate, the responses often seem to come out of left field. I'm following a different approach and hoping to come up with something better than that.

Visual representation of semantic net database, 08/06/16

I've been working aggressively on his linguistic abilities over the past few months. He can parse simple subject-verb-object sentences with or without prepositional phrases, like "A cat is an animal" or "A yellow bird sings in the morning," with some rudimentary support for compound nouns and proper names. He tries to figure out how each word functions in the sentence; if he can't get it due to insufficient background knowledge, he'll ask for clarification (a normal chatbot would just try to fake it). So far he just socks information away in his database and doesn't say much back, but that's coming. Oh, that's coming.

Visual representation of semantic net database, 08/23/16

The semantic database can be represented as a graph … hence the images embedded in this post, which show a timeline of its growth, from July of last year up until this April 8. You can also get an idea of how the graph-drawing algorithm has changed over time. Each dot is a concept, and the lines are the relationships between them. When viewed live while Acuitas is running, the graph is interactive; I can pan, zoom, and hover my cursor over the dots for floating labels that show which word is associated with each.

Visual representation of semantic database, 04/08/17

Since I'm putting some earnest effort into Acuitas this year, I'm going to try making myself write a fairly regular developer diary … maybe once a month. Watch me do cool things and struggle. Talking seems easy until you've tried to teach a computer to do it …

Code base: 4901 lines
Words known: 631

Tuesday, February 2, 2016

Artificial Muscle Brain Dump

Hello readers!  I've finally taken everything that I know (or think I know) about nylon monofilament artificial muscles and rolled it up into one page that I hope can serve as a fairly comprehensive how-to and a handy list of related resources.  If I run across any new discoveries, I'll be adding them there as time goes on.  You can read the page here:  It will also be perpetually available under the "Special Treasures" heading in the right-hand sidebar.

Happy coiling!

Tuesday, December 29, 2015

Artificial Muscles Actuating Things

They're still not terribly fast, and they don't move terribly far, but I've arrived at the crucial step of getting artificial muscles to actuate something more than just a weight hanging from a string. First up, we have a heterochiral muscle (the type that expand when heated) flexing a piece of paper. Each coil of the muscle is sewn to the paper on one side with a loop of thread, so the coils expand on one side and are constrained on the other, causing the paper to bend. This is almost a no-load movement, and strikes me as being most useful for something decorative, such as an artificial plant. You might notice that the cooling cycle is almost as quick as the heating cycle. I attribute that to chilly ambient temperatures in the upstairs laboratory.

Next we have a homochiral (contracting) muscle, rotating a piece of cardboard on a hinge. The opposing force of the rubber band on the opposite side pulls the cardboard back into its original position during the cooling cycle. The homochiral muscle featured in the video has been annealed with some space between the coils when at rest, so it doesn't have to be put under tension in order to have working room.

Both of these muscles are drawing about 1 A of current. They are made of Trilene Big Game fishing line, test strength 50 lb., diameter 711 um, with a heating element of 10/46 copper litz wire. The homochiral muscle has two strands wired in parallel. The heterochiral muscle was coiled on a rod of 3/16” diameter, while the homochiral muscle was coiled on a 1/8” rod.

Annealing muscles with built-in coil spacing

I determined in some previousexperiments that trying to spread the coils of a homochiral muscle when one first coils it on the rod is a bad idea. At this point there is a great deal of tension on the line – it wants to uncoil itself – and the coils don't cooperate very well. Coiling the muscle on a threaded rod is a possibility that I haven't tried yet; the spacing of the threads would limit the coil spacings one could achieve.

I started looking at ways to adjust the coil spacing after the initial annealing. First, I tried putting the muscle under tension (with no rod in the center) and running a high current through the heating wire, hoping to anneal it into its new shape. This method gives the most even coil spacing one could ask for, but the amount of heat applied to the muscle was only sufficient to “soft-set” it. I noticed that as it sat around for a few days, the coils slowly returned to their original close-packed configuration. When I tried annealing a muscle under tension at full heat in the oven, without a supporting rod in the center, the coils just went flat.

In the end, the best method I found was to put the muscle through its first annealing phase, manually spread the coils on the rod, then anneal it a second time. It's a little tedious – friction holds the coils against the rod, so you have to slide each one into the right position with your fingernail to get the spacing even – but it seems to work.

A close-up photo of the homochiral muscle with spread coils

An aside about plastic springs

In addition to artificial muscles, you can make simple passive springs by coiling nylon monofilament around a rod and annealing it (without primary twisting or a heating wire). The spring constant is determined by the thickness of the filament (larger diameters yield larger constants) and the size of the rod (smaller diameters yield larger constants). I got rather excited about this a few months ago, thinking I'd never need to buy a spring again. The problem is, these plastic springs don't necessarily hold up well.

If you follow any of my social media feeds, you might remember when I posted this spider leg video. There's a plastic spring at each joint, made from the 533 um Zebcom Omniflex line, and I'm actuating them by pulling the tendons with my fingers:

I took that video the day I finished building the leg. A few days later, the leg was in sorry shape, merely because I had allowed my house to heat up in the afternoons. This was sufficient to make the springs relax a good deal, so that I had to shorten them to get the same degree of tension I had before.

Naturally, this leaves me in some concern about the muscles as well. How might they be affected by high ambient temperatures? I haven't done any tests in which I compared a muscle's performance across many sessions of operation, with temperature spikes in between.

Blog news

Comments now require moderator approval, because spammers have been really junking up the place. Sorry.

In the new year, I think I'm going to try to build an “artificial muscle summary” page featuring everything I've learned, for the benefit of others who want to experiment. Once that's done, I may set muscles aside for a while. There are soooo many other things I want to work on.

Have a most excellent New Year!
-- Jenny

Monday, August 31, 2015

DIY Nylon Muscles VII

IT'S A NEW MUSCLE POST, EVERYONE! Sorry, I got distracted by other projects and life in general. One note before I get into my most recent work: I am now collecting other blogs/sites that deal with nylon muscles in the right-hand sidebar. If you run or know of a site that isn't listed, please tip me off so I can include it.

There were several things I got very tired of while experimenting on these muscles, and one of them was trying to measure deflections on the order of millimeters by squinting at a ruler mounted beside the muscle. Dangling everything from the edge of the dining table or ottoman was a bit awkward too. So I built myself a muscle test rig out of scrap wood. It provides a place to suspend an actuator and a weight and converts the linear motion of the actuator into the angular motion of a long needle. Small movements at one end of the needle are amplified at the other end, making them easier to see and measure.

The first version of the test rig just had a needle which pivoted on a piece of stiff wire driven through the board behind it. The pivot point was located very close to one end of the needle, and on the short end there were too loops of wire attached to the needle: one to connect the muscle, and the other to connect the weight. This arrangement left some things to be desired. For one thing, I could never get the wire perfectly straight, or constrain the needle so that it would lie flush with the graduated backdrop. That meant the needle's rotation was not planar, or it would stick as it turned, etc. On top of that, the motion of the short end of the needle didn't leave the muscle free to move straight up and down. Near the needle's zero point, the motion of the muscle is approximately vertical … but as the needle continues to rotate, its end begins moving more and more in a horizontal direction, changing the mechanical advantage the muscle has and introducing complications that I would rather not deal with.

 Left: Muscle suspending weight on deflection test rig, version 1.  Right: close-up of the reel on version 2.

Wanting something better, I replaced this lever system with a reel. A screw through the center of the reel provides it with a rotary axle. Two strings are tied to holes in the reel and wrap around it so that unwinding one string winds the other. When both strings are put under tension, they remain perpendicular to the side of the reel, regardless of the reel's angular position. I connect one string to the muscle and hang the weight from the other string, and the muscle is forced to lift the weight when it contracts. The needle is a piece of thin aluminum tubing inserted into a hole in one side of the reel; I can “zero” it by adjusting the length of string between the muscle and the reel. (I knotted multiple loops in the string, and a piece of flexible wire between the muscle end and one of the loops is helpful for getting things just right.)

For testing muscles that only contract over a short distance, this thing is amazing. No more staring at the muscle and thinking, Huh, is it doing something? I'm not quite sure. When the muscle starts moving, I get an obvious deflection out of the needle. The biggest remaining issue is that there's enough friction and/or elasticity in the system that there isn't a well-defined zero point for the needle. For a given muscle-and-weight setup hanging passively (muscle is turned off), there's a fairly wide angular range within which I can position the needle and have it remain stable. When I take a muscle through a heat-cool cycle, the needle generally doesn't return to its original position at the end of the cool cycle. How much of this is due to the muscle stretching out and how much is just the equipment, I unfortunately can't say.

The other little quality-of-life improvement I attempted for this round of muscle experiments has to do with ease of manufacturing. I was sick of going through the effort of making a muscle, only to have the fragile heating wire snap at the last minute. When that happens, the nylon can't be returned to its pristine state, and now the wire is too short – so often I would be forced to throw everything away and start over. Putting extra slack in the wire could result in bunching and loose wire coils, promoting uneven and inefficient heating of the muscle. So I tried a couple of different methods to relieve strain on the wire and keep it unified with the nylon.

Coiling a muscle with tape tags.
 For Method 1, I tried attaching the wire to the nylon at intervals of a couple inches, using little tags of adhesive tape. These can be removed after annealing by sliding a straight pin in next to the nylon and pulling outward to separate the two sides of the tape tag. Method 2 was a little more wild: I tacked the wire to the nylon by coating both with a thin layer of silicone caulk. Messy as it sounds, I found that the best way to apply this was to stroke it on with my fingers. It cleans up just fine with some mineral spirits (paint thinner).

In the end, I'm not sure if either trick helped a lot. For each method, I made four muscles and lost one out of the four (due to snapped wire). That's not horrible, but certainly not great either. I did seem to get nice even coiling of the wire around the nylon.

Besides trying out these manufacturing tricks, the principal experiment for this month involved rod-coiled muscles with spread coils. I had previously noted that the muscles with a smaller coil diameter could lift more weight, but had difficulty achieving a good contraction distance because their coils were already so tightly packed. I thought that coiling them around the rod with some spacing between the coils might improve that situation.

Actually doing this turned out to be harder than I expected. Homochiral muscles naturally form close-packed secondary windings. You have to fight the muscle to get it to lie on the rod any other way – and the small-diameter ones fight pretty hard. What you see in the photo is the best I could do. The mandrel diameter used for all of these is ~1 mm (large size paperclip wire). One of each type has a silicone coating, and one doesn't. The close-packed “controls” are on the top, and the ones with spread coils are on the bottom.

Yeeccch. Those look terrible. But I decided to see if they would work anyway. I used a current of ~220 mA and ran a bunch of tests with different weights. All the muscles were allowed to heat for at least 4 minutes and cool for at least 9 minutes, with the idea that this would be sufficient time for them to reach “steady state.” Results are given in terms of the needle displacement in degrees, and represent the maximum distance the needle moved from whatever its initial position was. An entry of “failure” in the table means that the muscle started to stretch under the load when heated, i.e. the needle displacement was negative. None of these muscles went flat or limp and became permanently unusable. For all the muscles, the lightest-weight test was the last one performed.

Muscle lifting @ 220 mA
71.6 g
60.0 g
50.0 g
25.0 g
Muscle 1: Packed, no silicone
Muscle 2: Spread, no silicone
Muscle 3: Packed, silicone
Muscle 4: Spread, silicone

Thanks to the new test rig, I think these are more reliable than results I've posted previously – but you should still take them with a grain of salt, because running the tests spanned a hot summer afternoon, and I can't hold ambient temperature in the house constant. I wish I could repeat all of these many times and take an average, but I really don't have the time right now. So I'm putting up what results I have.

With that disclaimer out of the way – the plain old close-packed muscle without silicone is the best performer by a good margin. I wanted to see if the silicone coating would have any detrimental effects on the properties of the muscle, and it appears that it did … so even if it does help cut down on manufacturing failures, it's probably not a good choice. My awkward attempt to spread the coils on the annealing rod doesn't appear to have panned out well either. But that doesn't mean spread-coil muscles are entirely out of the question.

Perhaps one could wrap the muscle around the rod with close-packed coils – as it is naturally inclined to configure itself – and anneal it that way, achieving nice, even coils. Then the muscle could be removed from the rod, put under load and stretched a fixed distance, and annealed again by running an especially high current through the heating element. I suspect this would achieve much nicer results.

Lots of failure in this post, in that none of my little “improvements” really worked out for the better – but maybe someone else can avoid the same dead ends.

Until the next cycle,