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:

np_nifalcon Max External Tutorial

PureData:

np_nifalcon PureData External Tutorial

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.

The Inside of the Falcon

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):

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:

Novint Falcon Packaging

Novint Falcon Packaging

Novint Falcon Packaging

Novint Falcon Packaging


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.