Rhombic Dodecahedron

Another magnetic tile polyhedron--the rhombic dodecahedron.

http://www.thingiverse.com/thing:2031961

https://github.com/eshira/polyhedra/tree/master/Rhombic-Dodecahedron

ThinkPad X200 Tablet as peripheral device Attempt 1

The goal of this project is to turn a "Wacom Penabled" Thinkpad Laptop into a peripheral screen and input device for my main Windows PC machines.

This documents just the first attempt, as not everything is working yet and I need to move on to other projects for a while.

The starting point: I have a Wacom Penabled ThinkPad x200 Lenovo Machine, pictured below. I read the following articles to figure out how I might go about my goal: article 1, article 2

The instructions from the article above were not sufficient for my setup and included some steps I skipped. Below are the steps I took to get as far as I have so far.

I installed Ubuntu (latest desktop version) on the Thinkpad machine. It installed cleanly alongside my existing Windows 7 install without need for any other tools (such as WUBI  mentioned in the articles). The pen worked out of the box on this system.

I verified the port of the pen with the following command (the port is /dev/ttyS4 for me)

dmesg | grep ttyS 

I installed ser2net:

sudo apt-get install ser2net

And changed the configuration file located at /etc/ser2net.conf and added the following line at the bottom section:

7000:telnet:600:/dev/ttyS4:38400 remctl NONE 1STOPBIT 8DATABITS -XONXOFF -RTSCTS -LOCAL 

I added my username to the group dialout with this line:

sudo adduser myusername dialout

At this point, I was not able to see the output of the pen on port /dev/ttyS4 because all attempts to access manually it gave me a resource busy error. I fixed this by commenting out the second to last line in /lib/udev/rules.d/69-wacom.rules. This steps should require a restart of the machine afterwards in order to have effect. The line to comment out reads as follows, with comments:

# comment out the next line if your distribution does not provide systemd
# If a /dev/ttySx device with the WACf name is detected, start the
# wacom-inputattach service with the kernel name as parameter
# SUBSYSTEM=="tty|pnp", KERNEL=="ttyS[0-9]*", ATTRS{id}=="WACf*", TAG+="systemd", ENV{SYSTEMD_WANTS}+="wacom-inputattach@%k.service"

Now it is also necessary to disable the Wacom pen services from xinput. If not done, streaming the data out with the cat command will make the computer behave erratically, and probably caused the kernel panic I experienced once as well. To list the devices, use command "xinput" which will return a list with ID numbers listed to the right. I found three Wacom entries under Virtual Core Pointer. They were the stylus, eraser, and touch. They had IDs of 12, 13, and 14 respectively. I disabled all three with commands as follows. These should be put in a start up script, as otherwise they must be manually entered with each start up of the system, possibly including log ins.

xinput disable 12

xinput disable 13 

xinput disable 14

At this point the pen won't work on Ubuntu anymore, which shouldn't be a problem because the goal is just to get the data over to the Windows machine anyway.

Now I can finally test the device locally. I entered the following command and saw data (unintelligible gibberish symbols as displayed) come out whenever I touched the stylus to the screen.

sudo cat /dev/ttyS4

Now I opened up a PuTTY session on the Windows PC . I set it up to 'Connection Type: Telnet', 'Port: 7000', and host name as the IP of the Ubuntu machine on the network which I identified using the command 'ifconfig' on the Ubuntu machine. The connected network interface, which for me is called wls1 and indicates my wireless card, states the address on the second line. It looks something like the following:

inet addr: 192.168.1.150

With the address entered into the 'Hostname (or IP address)' field I hit the "Open" button and saw that whenever I moved the pen to the Ubuntu screen, unintelligible symbols appeared in the window. Excellent. [Note: close the PuTTY winow after this test]

The only remaining steps were to get the Wacom modified tablet drivers to work and install HW VSP. I only made half-successful progress here, so I won't write it up yet in detail. I followed the instructions for the drivers from article 2. I tried this on two Windows machines each running Windows 7.

On my desktop computer, the Wacom drivers (installed per the instructions on  seem to be the issue. I get a complaint about them every time I boot the machine, and the HW VSP says "connected" but all the packets end up just adding to the number in the Queued section, and the VSP fields other than Status all remain blank. On the Windows 7 laptop, I do not get the Wacom drivers complaining at me, and the HW VSP window shows some values for all the VSP fields, as well as incrementing values for Rx and Tx packets in the VSP column. But the pen on the Ubuntu machine still does not move the pen on the PC.

For now I'm shifting gears away from this project, but hopefully I can get it working in the future. The Windows drivers are clearly the problem, and I've tried a lot of things, including other drivers, as well as messing with the registry and the driver files. I might have more success going through a second Ubuntu machine and using Ubuntu tools and drivers here. But the point is in part to get this working for a Windows PC, just because of my software and OS use patterns (I develop on Ubuntu, but use design and entertainment software on Windows).

If you think you have a solution let me know!

Simple Educational Robot Arm with Inverse Kinematics

The point of this project is to test a lesson that covers the theory and construction of a simple, two degree of freedom robot arm that moves in a plane and is controlled by specifying the X and Y position of the end of the arm (the 'hand'), rather than by specifying the angles of the two servos directly.

I ran most of this lesson last year at a summer camp, but due to limited time/high variance in math background of the students, we weren't able to reach the point I wanted to reach. (Really what happened is that I volunteered to have another class join my class for three hours for an activity, which meant a lot of my prep time ended up being soldering leads on more potentiometers...)

This activity seemed promising so I went through it again, at a less hectic pace this time, to try and make a list of the tricky 'gotchas' that would be useful to provide as hints if the goal was to have most of the students complete the project in the class time allotted.

Students who have completed a class covering trigonometry should have sufficient mathematical background to cover the math, which is described nicely on this page: http://www.learnaboutrobots.com/inverseKinematics.htm

A partial list of the tricky parts students may get stuck on (beginners tend to try to build the whole thing at once; a few compound problems can make it very difficult to debug):

• Constructing the arm so it is sturdy enough to last until demonstration time.
• Including math.h and finding documentation for C trig functions
• Keeping track of radians vs degrees
• Measuring link lengths accurately and setting up the physical arm to match the model (the arm should physically be perfectly straight  line if both servos are at their max range
• Mapping the analog inputs (reading from the potentiometers) to a reasonable range of the X and Y axis, in accordance with the units chosen for specifying the link length in the code
• Dealing with floating point error--floating point operations are not the optimal solution here but the goal here is to avoid adding more complex C programming concepts onto an already dense lesson. See the code for more detail. A good summary of the issues can be found here: http://www.engblaze.com/faster-code-fridays-avoid-floating-point-math/
• Using a separate power supply or filtering the Arduino power supply. The arm can otherwise get stuck in a cycle where servo moves, drawing a lot of power momentarily, which causes the analog inputs to jitter (and the onboard LEDs to flicker), which causes a new reading which causes the servo to move... Most students will use the separate power supply if it is provided, but it is also common for students to forget and tie everything to a single rail.

Here's an illustration of an issue that will happen if the student mounts the second link so that it cannot fold inwards. The green area on the left shows where the end of the second link (the 'hand') can reach. The shape is awkward to navigate. The right hand side shows the area reached by a better choice of angle limits for the second link. If it can fold inward, similar to how a human forearm/elbow/upper arm works, then it is easier to use. (This image assumes links are equal length).

I did mount the second servo flipped downwards, to reduce overall height of the assembly. That was a mistake in hindsight, because it means the arm can collide with itself.

Here's a video of the test arm I built, demonstrating that it more or less works correctly.

Finally here's the sketch. It isn't clean or commented...but I've decided it is better to share these things than to never get around to it at all.

Arduino Sketch for this project

Talking Calipers 1

At a recent Sector67 monthly meeting, a member who teaches at a school for the blind and visually impaired mentioned a need for talking calipers. They are hard to find for sale and they typically cost in the realm of $250, though if you have a link to something significantly cheaper please let me know. My overall goal is to design a cheap little add-on that slots on to standard calipers that have a serial output already. This post is about the first step: a quick talking calipers proof of concept. Here's a picture of the working setup. See bottom of post for a video of the setup in action.

Here's what's in the photo. Everything came from either my collection of prototyping stuff, or from the collection of a fellow Sector member who took interest in this project.

• Arduino Uno and Wave shield https://www.adafruit.com/product/94
• Standard cheap calipers
• Adjustable breadboard power supply https://www.adafruit.com/product/184
• Logic Level Converter https://www.sparkfun.com/products/12009
• Earbuds
• A push button switch

If you add up the total cost of the items listed above, it comes out to about $85...so already cheaper than the $250 price point. (I'm aiming to get the total cost down a lot further than that though).

Here's how it all works together. The calipers are bumped up from their usual 1.5 volt voltage from the coin cell, to a 1.9 volt supply from the breadboard power supply. This makes it so that the logic level converter works with the signal from the calipers (because the minimum signal it will support is 1.8 volts, so 1.5 is too low). The signal from the calipers is easy to access; there's a port on the calipers accessible by a removable plastic cover. On the other end of the logic level converter we have the Arduino at 5 volts.

The wave shield comes with it's own example code. The calipers communication protocol has already been reversed engineering by a number of folks online; I got my code snippet from http://nut-bolt.nl/2012/reading-digital-calipers-with-an-arduino/.

The main challenge here is that the Wave shield uses all the external interrupt pins on the Arduino. I needed to use a different kind of interrupt. After a brief read through the forums and the datasheet for the Atmega328P, I decided to use the analog comparator. Comparing against some code snippets made it a fairly easy job to set all the registers I wanted to the values I needed. I used the internal bandgap reference as the positive input to the comparator and my calipers CLOCK signal as the negative input. Then I set the interrupt to trigger on rising output edges. [Noting that the positive input to the comparator, Atmega pin AIN0, refers to Arduino pin D6, and the negative input to the comparator, Atmega pin AIN7, refers to Arduino pin D7.]

The code for this project is available here.

Here's the video:

Next up I'll tackle building a prototype of a cheap and portable version.

Cardboard-i-copter

Cardboard-i-copter wasn't a project so much as a fortuitous discovery.

A few years ago my uncle gifted me this quadcopter: https://www.amazon.com/gp/product/9269802574/

Unfortunately I couldn't get it to fly. It mostly chaotically bounced around the room. Friends with many more quadcopter flying hours than I all failed to get it to fly.

One night while hanging around the main Sector67 table, I pulled the roll cage off. Still no dice. So I disassembled it entirely, and then as a joke, taped the electronics and motors to cardboard.

It worked.

Nothing about this configuration was rigid or carefully measured or square. It seemed to self-right the motors so long as they were more than 45 degrees off the plane of the cardboard. It was pretty easy to fly. It was incredibly easy to repair after a crash.

Eventually it developed an issue with the control system that sometimes caused it to go full throttle and unresponsive. Those props are kind of painful to fingers and I was sick of chasing it down and fighting it to get the battery unplugged.

It would be fun to explore cardboard-i-copters more one day, formally (the physics of it), and informally (building a bunch of designs). If you have some cheap mini quadcopters or quadcopter parts lying around, try it and let me know how it goes.