Yup, it took all of a month for my "no new speaking until I have something new to say" thing to fall apart. But, well, this is different! Really! Somehow. :)

So yeah, I'm now part of the BDSM and Web 2.0 panel at the 12th Annual Leather Leadership Conference. The panel takes place Sunday, April 13th, at 10:30am. The panel will include Thomas Roche (who I was also on a panel with at Arse Elektronika, now of kink.com), Richard Hunter (of Mr. S Leather), Steve Bower (Webmaster for the Society of Janus), and others. Should be fun!

Well, v0.2 of libnifalcon is all done. Yay. That took a lot more work than I thought it would.

Of course, I've also now run into the nasty fact that libftdi is around 4x slower than ftd2xx, meaning that what's a 1000hz update rate on windows ends up being 300hz max on Linux and OS X. Not happy about this at /all/, but there's really not much I can do outside of porting to a kernel driver probably. Which, yeah, I've thought about doing, because I hate myself.

Anyways, I've also finished Max and Pd patches for the falcon for all platforms, thus my first real released "application" for this. Only took me 9 months. Go me.

Now then, see if you can figure out which program is the free one, and which one is the expensive one:

Max/MSP:

PureData:

Is there such a thing as a pretty PD patch? I have yet to see one.

Update: libnifalcon is still alive and kicking. The new url for it is http://libnifalcon.nonpolynomial.com. All of the up to date information can be found there.

After my article on the Novint Falcon box got linked by GameSetWatch and Ars Technica, it seems like it might be time to do a nice, technical throwdown about what's going on, inside and out of the novint falcon, since everyone else seems hung up on games usage (I guess it's a game controller, but that's not the fun part!). I've been working with the Falcon since early August, and am actually getting fairly far with it.

If you didn't understand my box article, read on anyways. I'm gonna try to make this as understandable to everyone as possible, so you'll all learn C and inverse kinematics and algebraic geometry and come romp with me down the happy streets of writing a driver for a badly marketed piece of hardware no one is buying.

Come on, what other relaxing hobbies do you have that involve Jacobian Matrices, hmmmmm?

Please note: I have not used Novint's SDK. I do not plan on using Novint's SDK (That would be cheating). I don't know what their developer support is like (though Tom seems nice enough on the forums. Hi Tom!). What you see here is what I've gained from lots of web searching, talking to people that know what they're doing (I'm not a haptics engineer, in fact, this is my project to learn haptics engineering and programming), and randomly trying things while hoping I don't break the falcon. I'll wikify all of this information in time, but it's honestly much faster for me to brain dump in conversational blog mode than it is into a wiki.

So what the God Damn Hell is the Falcon anyways?!?!

It's everyone's favorite time of class, video time! wheels in the TV with bad color and hissing, blinking 12:00 VCR

Seriously. I can't figure out how to explain it. Novint can't figure out how to explain it. So, watch this video, which tries to explain it.

If you don't understand what it is yet, well, I can't help you anymore. But enjoy this randomly technical description that follows anyways. I worked hard on it, and I did it JUST FOR YOU. Yes, you.

A Little Background on Parallel Robots and Haptic Controllers

Before we dig into the guts, let's start with what you can find out before you take the case off the thing. For reference, here's a picture of the Falcon:

A bit of background (this will contain much glossing as I'd like to focus on the falcon, but it's good to have a knowledge of what's out there otherwise). In the world of haptics, there are two major types of controllers. Serial (pen type controllers), and parallel. An overview of a bunch of the different hardware types is available in an article on bracina.com.

The NovInt Falcon is a parallel robot. Parallel robots are called such because they have multiple chains of joints working together to create the final position of the controller (or end effector, if you want to be technical about it). Not to mention, the math uses parallelograms to line up the positions.

If you watch a lot of How It Works (which, if you have cable with the Discovery Channel, you invariably end up doing no matter what. That show is video heroin.), you've seen these before.

They're real popular in pick and place operations. That's exactly what it sounds like. Pick something up, put it somewhere else. Repeat ad inifinitum. Puttin' things in or on other things. They're good at that.

Here's one in action.

So, you're probably like "But it's all pointing down"

Ok, look more familiar now? The NovInt Falcon is a parallel robot turned on its side. It's actually a Delta variant of the parallel manipulator (Here's a nice overview of the Delta Haptic Device, which is quite similar to the Falcon/Omega setup). If you want all sorts of interesting history about where it came from, check out this article on parallemics.org. But for now, we'll just say: France. It came from France.

There's lots of reasons why using parallel robots in haptics is important. However, I don't quite understand the math behind it all yet, so I'll just repeat what all the webpages say. "Good stiffness and accuracy in a small workspace". Having used some serial controllers before, I can see what they mean. Hard definitely feels... hard. I'm sure I'll be talking more about this in later articles on the development of libnifalcon.

To show a bit of what else is out there, here's the ForceDimension and their Omega series of controllers.

Once again, looks familiar, no?

Well, one major difference.

The Falcon is $249US.

The Omega starts at around $20,000US (the more degrees of freedom, the more expensive. The Omega 7 is around $50k.)

Ok, and the Omega comes with a PCI interface and all sorts of APIs and what not and FD is actually an offshoot of the subset of France that we mentioned above that created this whole thing in the first place, but still. That's some significant 0's worth of difference there.

There's rumors that ForceDimension helped out on the Falcon design. There's also rumors that it came from Sandia with Tom. Only Art Bell truly knows.

So why all this about parallel robots? Well, many future posts will be talking about research in this field, so I figured I'd at least introduce the term. There's also lots of reference and searchable material in here if you're interested in going your own direction with this information. Anyways, back to hackyness.

Internal Circuitry

Now that we've got that out of the way, what's inside it?

Click the image below to go to an annotated flickr picture of the insides.

Connectors:

• USB B Connector
• Power Connector - goes to 30V 1A wall wart of DOOM

Yes, the falcon is quite possibly cranking 30W through the motors when you max the torque on all the axes.

Chips (Links to Datasheets or Product Websites):

• FTDI FT232R USB to Serial Chip
• PIC 16F688 Microcontroller
• TI TMS320 R2811 DSP Processor

I don't have specific parts on the 3 motor blocks in the circuit (they're all exactly the same), but what you've basically got going on there is three really large old style mouse encoders. Each of the 3 large wheels attached to the motors have a disc attached to them, alternating little clear slots with opaque slots. There's a photoresistor that shines light through those slots. Whenever the light goes through (clear), you get a 1. Whenever the light is blocked (opaque), you get a zero. And that's how we know how far the motor has gone.

Whether direction is measured using some sort of quadrature encoding or Back-EMF polarity is something I forgot to check (but will do so at the point where I can figure out how to write my own firmware for this thing).

Communications and Initialization/Bootloading Sequence

Now, for the part I kinda sorta know more about than the other parts.

The Falcon uses the FTDI chip as it's main communications link to the computer. Everything is filtered back and forth through the FTDI chip, converting from USB on the computer side to RS232 on the circuit side. This is because it's orders of magnitude easier to program your microcontrollers to talk RS232 than it is to talk USB.

Novint distributes and uses the stock FTDI driver with their software. The only change they've made is to the VID and PID. They've chosen to use FTDI's free "have a PID" program, which has them listed under FTDI (0x0403) as a vendor, but with their own special product ID (0xcb48, as opposed to the default PID for FTDI chips, 0x6001).

NOTE: I have not actually proven this next paragraph, it's more what I think is going on than anything. You might've noticed in the Internal Circuitry section that there are two microcontrollers on the board: the PIC and the TI. This is where the bootloader sequence comes in. The TI DSP uC is actually reconfigurable on connection to a PC. The PIC acts as a bootloader, maintaining the logic needed to run the FTDI communications to pick up firmware and program the TI with it. This allows a developer (currently just Novint, since I've had no luck analyzing the pins. Stupid tiny LQFP pins and my shaky hand.) to possibly speed up the control loop on the internal processor depending on application specific needs. Damn fine idea, even if it did crank the price of the hardware quite a bit, I'm sure.

When a program wants to connect to the falcon, the following sequence occurs (if you want to follow along, check out nifalcon_libftdi.c). Note that the bauds get funky, because baud rate actually turns into a clock subdivision on the board, so I just converted the rate to the lowest clock subdivision possible that would still make them work. See the How I Mapped The Test Firmware Protocol section for more info.

• Open connection to FTDI chip
• The "Are we at least connected" Step:
• Set to 9600 8N1, No Flow Control, DTR High
• Write a 3 byte check message, {0x0a, 0x43, 0x0d}
• Read, expect 5 bytes back
• The "Send the firmware over" Step:
• Set 140000 baud, DTR Low
• Write a single byte (Usually 0x41 "A")
• Read, expect same byte back
• Send firmware file in 128 byte chunks
• Read, expect exact chunk we sent back from the falcon as error check
• The "Ready To Go" Step:
• Set baud to 1456213 (Maximum for the chip?)

After we've gotten this far, we're ready to run an I/O loop to the falcon.

The Test Firmware

So far, the only firmware that's usable with code I've written is what I call the "test" firmware. This is the NOVINT.BIN file included with the drivers, that the utilities in "c:\Program Files\Novint\Falcon\TestUtilities\" in a normal windows nVent (I HATE NVENT but that's an article for another day) install will use.

Rather than repeat the info here, if you're interested in the packet layout of the test firmware, check out my wiki page on it.

Note, however, that there are a few things you might not be aware of. First off, when you set a motor torque, it's only for a very short period of time (Haven't scoped out the exact value). Basically, you're expected to be polling the falcon constantly and setting the torques as needed. The controlling program is closing the control loop to the falcon, as just keeping torques on until next update can cause lots of badness (motor wear, crunched fingers, etc...)

Goals of the libnifalcon Project

So, that's pretty much all I know about this thing right now. I'm working on learning the math behind the haptics and placement algorithms, and while I learn, you'll get to learn along with me, in the form of reading my ridiculously long blog posts!

All of this is going into code form in the libnifalcon project on Sourceforge. As of this writing, v0.2 is sitting in the repository waiting for me to finish a few cleanup things.

Here's a few applications I have planned for libnifalcon:

• Max/MSP and PureData Patch (already done, just needs to be cleaned, threaded, and released. It's in the repository if you absolutely can't wait)
• Mouse movement/simulation
• Basic open source haptics library integration
• Mapping the TMS320 pins and possibly starting on my own firmware

As you can see, right now I'm more interested in getting a code platform built and teaching myself haptics programming from the ground up than I am in implementing any specific application. However, I do spend a lot of time in Pd playing with the falcon at the moment, and will most likely be posting interesting projects out of that in between code geekouts.

Aside 1: How I Mapped the Test Firmware Protocol

Mapping the test firmware protocol was fairly easy. I used SniffUSB to record the packets going to/from the Falcon in the test programs, then compared the data in those with the protocol mapping for the FTDI available in the libftdi source code. The bootloader code is basically a handwritten replay of this sequence, except translated back into FTDI driver calls instead of pure USB comms, hence some of the weirdness in the explanation (the "send 3 get back 5" seqeuence, the odd baud rates, etc...).

This was, quite literally, all it took. No amazingness or code breaking or whatever. Figuring out the packet setup was just a matter of mapping the numbers from the test GUI to the changing bytes of the packets.

Aside 2: FTD2XX versus libftdi, Operating Systems, and You

libnifalcon comes in two flavors right now.

• FTD2XX

• This is the driver that FTDI distributes, and the one that the default Windows Falcon drivers use. It seems fine on windows, outside of the fact that I personally have issues connecting the Falcon through a hub. This may or may not be due to my machine. However, this drivers seem wildly unstable on Mac and Linux. Also, they have no versions available for 64-bit Linux

• libftdi

• This is the free, reverse engineered version of FTDI's drivers, that use libusb. They seem to be stable across all platforms, though I only recommend using them for anything non-windows (or non-publically distributed on windows. Don't make people switch drivers if you don't have to.). It's GPL'd, too, so if you want to use libnifalcon under libftdi, you're stuck with the GPL too. Meh.

Having just finished up my libnifalcon page, I decided to post a few replies on the novint forums since libnifalcon had been coming up over there too over the past month, and since they haven't sued me yet, I figure I'm ok.

I also decided to post some observations I had about their packaging. Reposting here to get people's opinions, since I know more than a few designers (both game and print/web) read this blog:

First off, the packaging in question:

So I was picking up some Falcons at a local CompUSA closing sale ($49!), and while giggling to myself that I was getting falcons for cheap (now I have 3!), a random person asked me what these large boxes I was carrying across the store awkwardly were.

It's then that I realized: there were 5 falcons left at the store. This was the last day it was going to be open. They were $49. Not even the people picking stuff up cheap the rehawk in downtown were getting them. Not good.

After setting the boxes down and trying to explain why 3 DOF haptics is important for immersion (which boiled down to "stuff like, feels, and stuff"), I realized there's nothing on the boxes to explain to anyone without some training in haptics hardware (i.e. anyone without medical or industrial robotics experience) what a falcon /is/.

I realize this is a really, really hard problem. Everyone I know that's excited about the falcon falls into two groups:

(1) They have an advanced degree and knows how much this hardware costs when packaged as a research tool or

(2) They've actually used one.

The problem here is, neither of the groups can use word of mouth to convey the experience. It usually ends up in overly technical talk ("~1/800th inch encoder tick resolution per axis!"), or wild gesticulation and adjectives that don't quite fit the experience. Good for the user, bad for the uneducated customer. The choir can hardly preach to itself.

Not that I have any insight on this, but the box seems to be taken up by lots of pictures of the controller itself, with no informational diagrams about how it's used. In situations where you can't have one out (which is often, since it's awful big), this might help a lot.

Yup, it's spring again, and it snuck up on me this time.

First off, it's year 3 of GDC for me. Not speaking during the conference, though you can at least catch me at Brenda Braithwaite's Sex in Games Roundtables on Wednesday and Thursday, plus the various parties (Here's crossing my fingers for another World of Darkness party like last year. More game conferences need dominatrixes).

Wednesday, March 5th, it's off to O'Reillys Emerging Technologies Conference, where I'm giving a talk on the usual (teledildonics and intimate interfaces). Due to the fact that I'm poor and SD is expensive, I'm only in for the day of my talk, so look for me on Wednesday if you're around.

And then... Nothing. Yes, I have absolutely no planned speaking engagements after that, and I plan on keeping it that way for a while.

Well, I finally got new LEDs in, thanks to the nice people at Renoylds Electronics, who shipped another batch of LEDs after the first got lost in transit. I replaced the LEDs currently on the yoyo with OED-EL-1L2s, which have a 60 degree beam angle. This seems to have made a ton of difference, as the drawing program now makes tricks identifiable, especially with the scribbles where hold points are.

For instance, a sleeper:

And a trapeze:

Next step is getting all of this out of Max/MSP and into either PD or OpenFrameworks, as my Max demo license ran out and I'm not throwin' down the cash until they finally announce their pricing scheme for Max 5.

Taking some inspiration from Johnny Chung Lee's WiiMote Projects, I decided I'd like to figure out something neat to do with the WiiMote's IR Camera. I didn't realize that it's 1024x768 @ 100hz for up to 4 IR points (with 4 bits of depth, even), which gives you enough resolution to do some interesting stuff.

For those of you that haven't known me a while, you might not be aware that I used to yoyo quite a bit. I still play every so often, but not nearly as much as I used to. I ended up building up quite the collection, though. Something I always wanted to be able to do was yoyo tracking. I played a little bit with blob tracking and LEDs, but didn't have the hardware or experience back then (2000-2001ish) to really do what I wanted.

After seeing the head tracking and finger tracking videos, the first thing I thought of was trying the yoyo project again. Without taking the time to actually look at my collection, I decided to drill up an old freehand pog and electric tape it to my Pyro with a CR2032 pack attached to the back of the pog for power.

This ended up being such a colossally bad idea that I'm not gonna spend much time talking about it. The yoyo was unusably unbalanced. So, digging through my yoyo box somemore, I realized I still had some Torch LED pogs.

I removed the Red LED off of these and replaced it with an IR LED and a smaller resistor. Since I didn't really have any Spintastics yoyos I wanted to throw the pog in, I ended up dismantling my already sort of broken Night Moves 2 (the plastic on the axle end had cracked on it a while ago for some reason), and hot gluing the pog in to hold it. Sure enough, the yoyo was slightly unbalanced, but completely usable for most any trick. After ninja starring the pog due to not having hot glued it well enough the first time, I made sure to do a better job, and now I have an IR yoyo!

So, with yoyo+wiimote setup finished, I fired up Max/MSP and used the aka.objects wiiremote and appleremote externals along with the LCD object to make a little drawing program. The Apple Remote works as a pen start/stop and clearing device, so I can clear the screen and start/stop drawing while standing far back from the computer. The Wiimote external is wired to draw lines depending on the first IR readout from the camera.

The above picture is a drawing from that program, of an almost-but-not-really version of the "skin the gerbil" trick by Doctor Popular.

The picture also shows a couple of the current problems with the system. First off, I've completely trashed my office getting this done, so I can't back up very far and don't have a good idea of what the Wiimote is seeing. This could be fixed by calibration, which is something I plan on figuring out. Secondly, there's some sampling issue with large swings. Either my swings are causing tilt, the LED doesn't have a wide enough angle, or some combination of the two. I've ordered 5 more kinds of LEDs to test this.

Finally, I hooked up a little sample looper in Max/MSP to the setup so that it would spit out some noise, too.

This video is a combination of the drawing and the video, processed through Jitter. Warning, the sound is VERY desynchronized from the video. 100% of my experience with Jitter has happened in the last 24 hours, and apparently I missed something about getting the video to synchronize (realtime setting, maybe?), which is why the sound doesn't match the video.

So, that was my weekend. The project still has a long way to go. I've got 2 more Torch boards to mod once the LEDs come in, and it'll be interesting to see which LEDs work best. I should have those later this week. I also plan on modding a spintastics top I have that has a torch board in it, so I can do Augmented Reality Battle Tops.

Have any interesting ideas for this project? Please leave comments! Seems like there's a million places this could go.

The week of getting half-done projects to 3/4th done continues.

GENTLEMEN, BEHOLD:

Twitter Breakcore

I created this back in September, when I was taking my Max/MSP classes at RobotSpeak. I decided to try layering twitter public timeline messages run through text-to-speech over fairly simple looped break samples, because noise + noise = noise.

Unfortunately, either Py/Ext or flite~ is causing Max/MSP to crash about 20-30 minutes in, regularly, so having a full time stream running is a bit of an issue right now. However, I made a small 2.5 minute track.

"actively gnawing on some guy's head" (MP3, 2:20)

Lyrics:

systems over single channel, IP

Have fun and be safe. Happy New Year to you too. xx

Bob Sinclar Ft Steve Edwards - World Hold On (David Guetta And Joachim Garraud Remix)

Night Night everyone!!! xoxoxoxoxoxoxo

comiendo pizza con cerveza de tercio..... perfect

, do you ever get to see the wildlife?

the internet by design is a communications platform. the goal is to put old communications systems over single channel, IP

Back from dinner. Answering a few emails then watching Helvetica.

Christmas Cheer? MST3k Santa #521 on Google Video

mmmmm..... Ribs :). Lol

Back in Columbus. Found 5 dead roaches in my apartment. Bleh.

no run. GB Hogg to SC Ganguly, no run, fuller and on the off, driven hard but straight to cover

no run. MG Johnson to SR Tendulkar, no run, full and outside the off, left alone, this one doesn't bounce too much and scoots along to t ...

posteando

Spacetime Continuum - Kairo (Carl Craig Mix)

Helpful Tip: Don't let your brother-in-law take you to "I Am Legend."

Rosie - Another Rosie Christmas

Baby break dancing!

when am i coming by for pie again?

contestando mails de laburo :(

I love spark people ! Haha. Going to sleep soon.

Went to Kohl's tonight... I don't even know why I bother with that place.

Borre bastantes twiteros ke no twiteaban como hace 1 o 2 meses!...

congratulations on your laptop!

is it just me or does firefox seem to get less and less stable with every patch?

In San Jose, Ca

queda una no tan larga noche por delante.

"Arguments with furniture are rarely productive."

To be fair, it was actively gnawing on some guy's head when they shot it.

i'm in ur eharmonies, communicatin' wif ur matches.

Consider all videos in this post NSFW. :)

Yay. Full hour presentation up on Vimeo. Or, if you still want it in < 10 minute sized chunks:

• Part 1: Intro
• Part 2: Hardware Types
• Part 3: Audio and Teledildonic Control Interfaces
• Part 4: End User Programmable and Video Synchronization Interfaces
• Part 5: Video Game and "Other" Interfaces
• Part 6: Why DIY and Why We Should Care
• Part 7: The Future of Sex Tech
• Part 8: Research Example: Microtransaction Interfaces

I was just gonna paste the videos together, and then I decided "Maybe some music would be nice", and two hours later, here I am. I'm pretty happy with the result, though.