Software Scoring Machine

[griffindm]

A competing USB product (more expensive to be sure) Here shows a polling rate of 1 kHz, which gives you 1 ms response through the unit. That unit is too expensive for this use, but it does show it is possible with USB.

[jabalino]

Yep, the USB interface is ~8ms resolution. That may actually work out ok, because the shortest duration we really need to record is 14 ms (+1/-1), right? (The foil debounce time.) So if we see a tick at 16ms, it's pretty darn close. And who knows what happens on the hardware side of it... I would suppose that things just get buffered back, so something occurring the middle of the next tick would get rounded up anyway. That means something occurring at 8+5 seconds would get rounded up to 16 and the software would interpret it correctly as a hit. The rules say the range is 13-15ms anyway, so it ought to work. Everything else is instantaneous or of a longer duration. The epee timing is the next closest, but the rules indicate a range (40-50ms), so if we get 8ms ticks, we should be able to get the right timing if we set it low (at 40ms, so we'll catch it at 40 or 48). I tend to see 8ms ticks in windows anyway (although I've also see 6 ms times. why? who knows..). I'm going to do some tests on a linux platform and see what happens.

I chose the PS/2 version because it is supposed to be faster, and I think that's still the way of choice. Unfortunately, fewer and fewer computers (and especially laptops) come out with PS/2. In any case, it just needs it to be close enough. I don't think the FIE would ever in a million years certify this, and I don't even know what I would use to validate these times. Right now I'm relying on the computer to report the times accurately itself, which is a little flaky. But, even though we've only begun to test it, it _feels_ right for foil. The flick shots it registers and doesn't register match up to our experience fencing on other production boxes with the new timing. So if the USB isn't any better than the windows anyway (and as long as it's no worse) it should work, but I'll have to buy it, test it, and get back to you.

As far as the voice commands, yep, that's one of the coolest things. (And it was actually one of the easiest things to implement!) We use a bluetooth USB device to pick up the Jabra Jawbone. I use a neat little program called Shoot (http://clans.gameclubcentral.com/shoot/) that somebody wrote to relay keystroke macros from voice commands. I just wrote the program to interpret these keystrokes to do certain things, and I write my commands in Shoot. So, for instance, when I say, "On guard, ready, fence" it sends the keystroke to start the timer, and when I say "Halt" it sends the keystroke to stop the timer. If you didn't want to use voice, you could use a wireless keyboard or one one those presentation devices or whatever to send the keystrokes to do what you want. So there are countless ways to remotely control the box. I'm not really that interested stopping cheating (since I wouldn't ever expect this to be used at any high level competition, and probably not even locally), but the security controls for bluetooth should be good enough to prevent random people from fooling with the score, etc.

Everything else is indeed configurable. All the lockout times, debounce times, keyboard inputs, etc, can be configured. They currently aren't, but I wrote the program so that I could do it later (priority one was just to make it work at all). So the interface is a little weak right now, but I'll work on that after the basic testing and development is over. (Maybe make it skinnable - that would be pretty cool...)

Glad to see people are still tracking this thread! I was afraid that since it's been so long, that would have been abandoned.

-Tom

[brtech]

Uh, no, not quite.

In general, to time something, you need to sample at 2X the resolution you need. Here, you need 2 ms resolution (14 +/- 1), so you have to sample at a 1 ms rate. This would be the only way you could detect something was on for at least 14 +/- 1 ms.

I presume that on an 8ms sample, you want at least two samples of no connect to register a hit. So, suppose the first sample is T=0, the second was T=8, the third T=16, ...

Okay, suppose the hit starts at just a little before T=8 and goes off a little after T=16 You would detect a hit for a 8 ms no connect, a little more than half of what they are looking for.

[jabalino]

I don't really need to sample that 2ms interval, though. I just need to know greater than 14 or less than 14, with a +/-1ms error rate. I just look at events anyway, which is to say the timing of connections made and broken. So when a foil connection is open, I start a timer (which, thanks to some poor java implementation that has recently been fixed and I haven't implemented yet) is about 50ms (it was supposed to be the debounce time). Anyway, circuit is open, and I start that timer and log the time that that occurred. If it reaches the end of the timer without closing again, the touch is announced. In other words, if I plant the tip in someone's chest, I don't wait for the tip to rebound before I announce the touch. After a certain interval, I know it's a touch (in this case, 50ms).

If the circuit closes again before that time, I check the time it closed. If the interval between the time it closed and the time it opened is less than the debounce time, I stop the timer and nothing happens. If it is greater than the debounce time, I stop the timer and announce the touch.

The gist of this is that depending on how the hardware handles things, this may or may not work out on the hardware end with the USB version. I just ordered one, and I'll test it out. The PS/2 version doesn't have this problem, and that's why I think that's the method of choice. On the software end, windows timing is clearly less than ideal, and hopefully linux will help out with that somewhat. But again, even on the windows side (and with the PS2 adapter), it certainly _seems_ right with what it allows and doesn't allow on the debounce. My goal was to make a unit that was built from easy to get components, was easy to assemble, and works well enough for mid to upper level club fencing. As far as that goes, if the box seems to register the touches that I think it should, and doesn't register the ones I don't think it should, and I have a pretty good idea of what is what (based on flicks on other boxes), that's good enough for me.

And anyway, this only really applies to debounce times in foil. Everything else is long enough and had a big enough error range that it doesn't matter. The reality is that if it really is 8ms, most touches will be timed correctly, and a few on the margins won't. If anything that happens in the interval is sent on the next tick, then the probability that it will be counted is:

(time-resolution)/resolution

So a touch with a debounce of 13ms on an 8ms tick clock is (13-8)/8 or about 60%. a 15ms hit has an 87% chance of being counted. Anything under the resolution can't be counted, and anything twice the resolution will be counted. So the absolute failsafe on an 8ms clock is 16ms, which is pretty close. Eigertek says their Doha timing is 13ms, BTW. I actually find this probabilistic method kind of intriguing. Anyway, that's worst case with an 8ms clock. Clearly I would like to do better, but I think this is workable.

[FoilyDeath]

Not particularly relevant, but this would be very easy to put on a bootable USB key: not only that, but you could also put a windows version on it, just in case people don't actually want to boot into linux.

[brtech]

Either I'm misunderstanding what the USB interface does, or you aren't getting what you think you are getting.

If a one "tick" interval of the timer is around 8 ms, which is how I interpret "8 ms resolution", then you can measure increments of 8 ms plus or minus 8 ms. That can't measure anything close to 14 +/- 1. If that's not what "8 ms resolution means", then I don't understand the hardware.

I do know that all versions of Windows are totally non-deterministic with respect to any form of timing. Unless the timer itself is in the USB interface, you will see occasionally wildly off timings, which occur when the kernel code is not yielding to the interrupts often enough. Depending on how the code is using the built in timers, you can see seconds of delay.

[jabalino]

Right, but it's probabilistic. Depending on when when that first tick happens in relation to when the hit starts is going to determine whether that 10ms depression time is going to yield two "ticks" or three (at 8ms ticks). So a 9ms hit is going to be interpreted as in time (16ms) 12.5% of the time, and a 15ms hit is going to be interpreted as a hit 87.5% of the time. A 16 ms hit will _always_ register, and that's pretty close to the line - certainly close enough for most fencers, I would presume. It is more worrysome that a 9 or 10 ms hit will sometimes register. Even so, have you ever seen an accurate distribution of flick times at better than 1ms resolution? I'd be interested to see it. From what I understand about the history of the rule change, 14 ms was a pretty arbitrary choice.

As far as the windows timing goes, it's possible to have delays like that, but it should be pretty rare. And a more reliable operating system should have that problem at all. I mean, when was the last time you were typing something, with no other background processes going on, and the keys you typed just didn't show up? It used to happen, sure, but it doesn't anymore. As far as the more realistic shorter delays go, I don't think anybody knows the realistic probabilities of something like that.

Remember, the point is not to develop something that will replace the freestanding scoring box, but something that individuals and clubs can use to augment their scoring capability for in-house use that works well enough to permit bouting at mid-to-high levels of fencing quality. I would not advocate the use of this kind of box at this time for anything more than that.

[brtech]

Then run one of the real time Linux kernels and then you can probably even use a parallel port

[griffindm]

Does someone have info on where to download realtime linux kernals and their support for Java?

[brtech]

Google is your friend

http://www.linuxdevices.com/articles/AT8073314981.html

Probably look to RTAI or RTLinux

I've used the MontaVista stuff in real products

[jabalino]

Real time linux is the way to go, especially if you can put it on a bootable CD/DVD/ or thumbdrive. I think as a mitigation, though, the java app process could be assigned a real time priority in the windows task manager. Obviously not a total fix, but it may help in some cases. brtech - Yep, you could probably use a parallel port, but even fewer machines have those these days than PS/2. Looks like the Happ USB model that griffindm posted works at 1ms intervals. It's out of my price range for testing, though. If it can be done, though, the guys at keywiz will probably integrate it before too long, and for a much lower price.

First club test of the machine tonight, I'll let ya'll know how it goes.

[tkexi991]

Originally Posted by reawl

Epee is working. Though I discovered tonight that one parallel port dongle (there's got to be a better word than "dongle", maybe "adapter"?), isn't going to cut it. Foil sends a signal out the B lines, Epee out the A lines, and sabre out the C lines. This means I'd need six pins that work as both inputs and outputs; parallel ports only have 4 such pins

I haven't seen one in years, but you could use a parallel port switch box. We had a few around back in the college computer lab.

[griffindm]

Brtech,

Originally Posted by brtech

Google is your friend

http://www.linuxdevices.com/articles/AT8073314981.html

Probably look to RTAI or RTLinux

I've used the MontaVista stuff in real products

Yeh. I spent some time on that page. The more I investigated, the more I found that all of the current RT stuff (i.e. updated since 2004) has some patented portion and is aimed at the industrial and robotics market (read: "able to pay big bucks"). The remaining open source stuff is mostly university-based, and most of the related pages either no longer open from the provided links, or haven't been updated since 2004.

How is the Montevista linux priced? I can see that it is currently up to version 5, with an impressive list of features here. What was your impression of the product?

Dave

[brtech]

It's very nice, and we got good support (commercial product, we paid for support). It worked well for what we were doing. I'm sure it will work very well for this kind of app, but I'm pretty sure any of these kernels could do the job. All you need is one deterministic thread which can get at a high resolution timer. Any of the hard real time kernels can do that.

[jabalino]

http://www.geog.ucsb.edu/~pingel/FencingBox/

Software is up, as are screenshots, wiring diagrams, etc. Please note the limitations of the system - it's still clearly under development, and I've more work to do in detecting some more circuits. I'm pretty sure this won't work that well for sabre, but I never fence sabre, so I'm afraid that's going to be on the bottom of the development pile. Even so, you can look at the software, and if you want to spend about $25-35, you can build one! I still haven't received my USB version, so this is all only as pertains to the PS/2 version.

The interface is a little crude - that's also on the bottom of the pile, but you can try out the software and the voice control via the third party app Shoot (linked on the page).

Anyway, enjoy. Comments and feedback are warmly welcomed, but please keep them in the spirit of positive development. I'm not trying to sell this, just make it.

[griffindm]

Tom,

Very nice. I look forward to hearing about your testing of the USB version when it gets in. As you've said, the PS2 port is becoming more rare on laptops. I'll order by board and build mine up as soon as you find out if USB gives adequate results.

One nice feature to consider, if you don't already have it, is to log the events to a text file. I see the screen output in the screenshot, so copying it to a file should be trivial. The file could help answer a lot of questions as to the veracity of the results compared to the FIE specs. I know you're not shooting for a commercial level product, but the file could help in interpreting the fencers' 'feel' for the results.

I tried to bring the photos at the end of the website and got nothing but 404's.

As an alternative to the bluetooth headset, I imagine any one of the handheld presentation remotes could do the job reliably if it supports programmable keys.

Dave G

[jabalino]

Thanks for the heads up on the broken image links. They are fixed now!

[griffindm]

Tom,

Just wishing out loud here. How hard do you think it would be to link the program with some parallel port output control? As you are using the PS2 or USG HID to take input, those controllers could never provide output. If you could send some contol data to the printer port, it would not be too difficult to link that to a relay box to drive external lights! No timing issues there as driving lights does not have timing as an issue.

That would be a nice answer to the (valid) complaint that LCD screens do not provide enough viewing angle.

Dave

[jjefferies]

I scanned the thread and may have missed the important points. But has reawl described how his concept is to work? Other than the intentions to use an older (possibly discarded) computer and its parallel port(s)? One reason I ask is that the few designs I've seen in public seem to use pulsed signals with the specific line depending on the weapon. For instance epee would use the "AB" connection and the opponent's "C" (or ground). I've forgotten the arrangment with foil and saber. I believe one commentator mentioned this is standard in most modern scoring machines. Makes for lower voltage outputs. So has reawl posted his design to anyone for scrutiny and comment? Or is it here and I've just managed to miss it some how.

Also I'm (still) very interested in the FIE specs for scoring machines, i.e. how long the contact has to remain, debounce times, resistances etc. If anyone knows where this info is posted I'd appreciate a heads up.

[griffindm]

JJefferies,

The British Fencing Association has the "best" english translation of the current FIE rules. You can find them here.

There are no substantive differences from the USFA rules as far as timings currently.

Dave