www.jaycrowe.com

Not to worry--I didn't really think I'd hit anything on the first try. I think I'll wait until my magellan gets here to do more on that front.

re: 16 bit resolution from the spaceball devices - I found that out later when I read the document
http://lists.unc.edu/read/attachment/16 ... c.1.20.doc in part 4.2.2., among other locations.

Strangely, All of the web pages I have searched for say the resolution/sensitivity says 1024 levels, or 10 bits.

http://www.mindflux.com.au/products/spa ... 00flx.html
re: 4000FLX - says - Internal Resolution: 10 bits
http://www.xicomputer.com/support/drive ... part=20066
re: 5000FLX - says -Adjustable Sensitivity. -Internal Resolution - 10 bit.

Anyway,
I found a schematic in the PDF I got from doing a patent search, US #005798748, for a force and torque sensor. There are other patents related to this also.

http://www.patentstorm.us/patents/5798748/fulltext.html

I have been working on several different approaches. I tried to directly interface the balls wiring to the arduino board (soldering to the solder side), I at first tried using PortC (normally the analog input), Analog0 as the input, and Analog1 - Analog5 as digital outputs, 15 - 19 in Arduino digital pin# programming, (the pins are close together!)
I did get readback of the sensors data, but too random, unbuffered analog input, and I used resistors for current limiting on the LED's. My next attempt will be to use either an op-amp as the buffer, like they use in the original schematics, and/or use digital pins from the other side of the Arduino for the switching of the LED assembly directly, or through switching transistors, like the original schematics show.

I completely dissasembled one of my non-functioning 360's ball assembly, traced the color code, compared it to the schematic listed in the patent, they combined the two lines coming back from the optical sensor array into one return coming back. My 4000FLX has the same wire colors coming out of the bottom of the ball assy, so I am assuming they (SpaceTec) used the same ball assy for all of their devices.

Here's what I have so far:

color code from the ball assembly to the original SpaceOrb 360 board, left to right, referring to the schematic in Figure 20 of the above mentioned patent:

Purple - opto sensors high side, all 6 tied in parallel, to a/d sensor (not separate like in the schematic, straight to item 420, bypassing item 424, a switch.)
Blue - one of the 3 npn transistors labeled 412 (2n3904) (low side of LED bank)
N/C - blank - no connection -
Green - Ground, also low side of opto-sensor array.
Yellow - one of the 3 npn transistors labeled 412
Orange - one of the 3 npn transistors labeled 412
Red - one of the 3 PNP transistors labeled 408 (2n3906) (high side of LED bank)
Black - one of the 3 PNP transistors labeled 408 (2n3906) (high side of LED bank)

I haven't yet figured out which of the Blue/Yellow/Orange wires is X / Y / Z, or which of the Red or Black is for Force or Torque (rotation), I should have that over the next few days, using an oscilloscope on one of my functioning SpaceOrb360's.

Also, I have a Logitech Cyberman (3 button mouse on a pedestal, serial device), a Logitech Cyberman II (green puck, joystick port device), 5 SpaceOrb 360's, (one on "semi-permanent" loan to a friend), 2 working and 2 non-working, one of the working SpaceOrb 360's I got last month through Ebay for $1 plus shipping, I also got last month through Ebay a SpaceBall 4000 FLX and a SpaceMouse Magellan, both serial devices.

One of the web sites I looked at said the Cyberman II and the Magellan have either the same or similar technology, optical sensor wise.

Rob

Nice work, Rob!

Yeah, not sure on the 10-bits v 16-bits business. When the Magellan gets here I can speak a bit more knowledgeably on that after flailing with decoding it.

Victor,
I’ve been working on a sketch for Quake4 (and hopefully for games that doesn’t have joystick support) using your keyboard axis and button binding demos as resources. I have 5 axis “() is the demo axis value” (I didn’t use YR (4) axis, the game doesn’t support lean left & right) and 6 buttons working in the game. I have a problem with XR (3) & ZR (5) axis are so fast their uncontrollable. Axis X (0), Y (1) and Z (2) have great control so I don’t think using the Gain or Precision Gain would be practical...Gain would slow movement on all the axis and same goes for Precision Gain because the mask button would have to be pushed down constantly during game play.

I don’t understand how you calculated the min & max axis values in the Keyboard axis binding demo? I know the Orbs axis values go from 0 to 1023 but how did you come up with 0 to 255 for the minimum values and 768 to 1023 for the maximum Values? Do these min/max values have anything to do with sensitivity or are they just for the range of the axis? I tried changing these values on the problem axis in hopes of slowing their motion down but not knowing how they are calculated it didn’t work well.

Another value you use in the keyboard axis demo is “Modifiers”, the value is “0”. I don’t know what rule it has in the sketch? What does it do?

I would appreciate any info you have on my questions Victor.

I think what he did is, 512 being the center, anything below 255 becomes the minus direction (512 - 256), and anything above 768 (512 + 256) is the plus direction. Anything between 256 to 767 becomes the "null region".

Rob

Ron:

RadioBozo is right--the axis values are 0 to 1023, so the "minimum value" of 0 to 255 is the "Low zone" at which it will output the requisite character; same with 768 to 1023. You can pick ranges anywhere on the axis (for example if a game had separate keys for "walk" and "run", etc).

It sounds like I should maybe implement per-axis gain (you won't be like using keyboard bindings for pitch/yaw likely). I want to add something else as well--I thought the keyboard axis bindings would be great for controlling games a la WASD, but actually if you set the "dead zone" too small (say both X and Y axis have bindings from 0-500 and 525-1023) then it's very hard to just push one button (ie hard to get the X-axis far enough to register without pushing the Y-axis one way or the other). So I'll put in something with angles (such as a 4-way mapping which would only push one button of four directions, and an 8-way mapping, or some such).

Per-axis gain will be easy and should solve your problem. Give me a few days as things are slightly busy atm, but give the keyboard axis binding a try; you may like it.

Another value you use in the keyboard axis demo is “Modifiers”, the value is “0”. I don’t know what rule it has in the sketch? What does it do?

Modifiers are like shift, alt, etc--things that modify the other keys. See "hid_keys.h" in hardware/libraries/SpaceOrb.

Thank you Rob and Victor for explaining the axis values, I understand how the values are calculated now. I changed the values on the problem rotation axis many times trying to slow them down but the movement became jittery in the game.

I also tried adding the sensitivity curve to the sketch, that didn’t work well...I had to push very hard on the Orb for movement and the rotation axis were still as fast as a chipmunk on steroids!

vputz wrote:So I'll put in something with angles (such as a 4-way mapping which would only push one button of four directions, and an 8-way mapping, or some such).

If you do add in 4 & 8 way mapping for one button (or ball movement) you’ll have to explain how that works...remember, I’m mentally challenged with this programming stuff.

vputz wrote:Per-axis gain will be easy and should solve your problem. Give me a few days as things are slightly busy atm, but give the keyboard axis binding a try; you may like it.

Yes I would like it, when you have the time for adding per-axis gain that would be fantastic Victor! That way I could tame the rotation axis without interfering with X, Y and Z axis that are working great in the game.

vputz wrote:Modifiers are like shift, alt, etc--things that modify the other keys. See "hid_keys.h" in hardware/libraries/SpaceOrb.

Thank you for the info, after I submitted my post I reread your OrbShield documents and noticed how you used the modifier in your Keyboard Button binding sketch. I’ll check out your “hid_keys.h” in “spaceorb libraries” so I have a better understanding of how it works.

Ron--

Give this a go. This was a 15-minute fix which "seems" to work but hasn't been tested really thoroughly. The axis_gain_spaceorb.zip file contains the orb_translator.h file for the arduino/hardware/libraries directory, and the axis_gain_demo.zip file contains a new version of GainDemo.pde.

Basically the old set_gain and set_precision_gain still work, but set the gain/precision gain for all axes. I've added two more methods, set_axis_gain( axis, value ) and set_axis_precision_gain( axis, value ). The demo sets the gain and precision gain but then sets the x-axis (0; I'll put #defines or constants in the next round) to have a damped gain in regular use and an amplified gain for precision... so if you mash the orb a bit off center, y-axis will move further than x-axis, but if you hit button 0 (the precision mask) they will sort of swap.

It seems to work OK; just try setting the gain for the rotation axes (3 and 5?) to a lower number and see if it helps!

Vic

I didn't expect to hear from you so soon Victor... Thank you for the Gain files!

My testing of your new Gain Demo didn’t turn out well. I’ll explain what I did; I replaced the old Gain Demo with your new Demo in Arduino Sketches and did the same with the orb_tramslator.h file in the spaceorb libraries. Then added the new Gain files to my Quake4 Test Demo and added a second translator.set_axis_gain so I could adjust the gain values on the 2 (3 & 5) problem axis. I started with Gain value 10 and lowered the values one at a time. Each time I set the value lower I had to push on the orb harder for movement and it jumped quickly...no smoothness at all in the game. When I changed the gain value to 4 there wasn’t any movement on the 2 axis but they worked in the Control Panel test applet...the range was only half the normal range. I’m not able to give you Raw Data Values due to the problems I have with this sketch in the calibration applet.

Here is a copy of my Quake4 Test sketch so you can check it out, maybe I didn’t enter/use the Gain files as you intended.

Each time I set the value lower I had to push on the orb harder for movement and it jumped quickly...no smoothness at all in the game. When I changed the gain value to 4 there wasn’t any movement on the 2 axis but they worked in the Control Panel test applet...the range was only half the normal range.

Hmm. Looks like the Orb is doing exactly what we're telling it to, ie scaling the movement based on the gain we set. With the gain damped, it should indeed move at less range in the control panel applet.

(thinking)

Wait a sec--I reread your earlier post--are you doing this via keyboard bindings entirely, IE Quake4 is not reading the orb as a joystick? If that's the case, what's happening is that you're just changing when the orb decides to mash the keyboard button, and you will always spin at the same rate as you would if you were mashing the keyboard button. There's nothing we can do about that (although maybe setting something in the game to change the rate at which you turn and look).

Having said that... I don't have Quake 4, but I'm downloading the demo to play with it. Since I'm pretty sure Q4 is controllable with the mouse, we may have better luck with mouse axis bindings. I'll play with it, and that's not a bad thing to have working either. The mouse bindings aren't perfect (in particular they may feel "jittery" because they don't update as fast as a mouse would since they rely on orb packets) but I've been curious about this myself.

Ron:

Got it--partially. Check out attached sketch with mouse bindings; I think that's the way to go here. It's ALMOST right (the included sketch just has WASD and mouse bindings to the appropriate axes, plus button A is mouse0, B is mouse1). I tried this with the Q4 demo and it almost felt decent (note that it is mouse binding, so it will slew your mouse around like crazy out of the game if you're not careful).

However--there's a problem, which you'll see when you play Q4. The motion is "jittery" as I'd expected. The reason for this is that the orbduino only sends updates every time the orb receives a full packet, which is, say, every 13 characters at 9600 baud, or something, and maybe less than that. That's fine for a joystick, because the game may update really rapidly, but it's looking at a joystick value... if you hold the orb at "x=1", the game sees "1,1,1,1...". But with a mouse, the mouse doesn't appear to move at all, and then it gets the full update, so the game sees something more like "10,0,0,0,0,10,0,0,0...".

If you try the included sketch with Q4, you can see this when you turn--it turns at about the right rate, but your eye can definitely tell that it's not smooth. So it's a strange compromise. Give it a try.

Now, I know a probable solution: instead of sending a mouse update when I send an orb update, I can send a mouse update every character (or so) based on the last axis value. This will smooth things tremendously and will probably work OK (though I'm not sure), but will take me a day or so.

Thank you Victor for the Q4 file, I know you are busy and I do appreciate you taking the time to help with my sketch problems. I downloaded your Q4 file and I’ll test the file and reply to your post tomorrow night. I had a very long day, my dad isn’t doing very well and I’m going to spend sometime with him tonight.

Actually, Ron, you have no idea how much I appreciate you trying to do new things with it; whenever you run into problems, it shows me where I've left something missing. So this is good stuff, but no rush. Take care of your Dad; family's precious stuff.

vputz wrote:I reread your earlier post--are you doing this via keyboard bindings entirely, IE Quake4 is not reading the orb as a joystick? If that's the case, what's happening is that you're just changing when the orb decides to mash the keyboard button, and you will always spin at the same rate as you would if you were mashing the keyboard button.

Yes Victor, I was using all keyboard axis bindings in my Quake4 sketch. In your OrbShield documentation under “Keyboard Axis Binding” it states;

“Many games do not support joysticks, or if they do they do not support six-axis controllers such as the SpaceOrb. To add to the flexibility of the SpaceOrb, we implemented the ability to bind keyboard key presses to various axis ranges”

So I looked at it this way, if some of the axis worked well as key presses in the game the others should also. That is why I questioned the axis values (ranges) in my earlier post. After you explained how the key presses work (spin at the same rate) I now understand what I done wrong...I think?

vputz wrote:If you try the included sketch with Q4, you can see this when you turn--it turns at about the right rate, but your eye can definitely tell that it's not smooth. So it's a strange compromise. Give it a try.

I gave the Q4 sketch a good workout last tonight and I am very impressed, it works a lot better then my sketch! No, it isn’t as smooth as it could be but it wasn’t that bad either. I did have a bit of a hard time controlling strafe (move left and right) but you’re on the right track Victor and I am looking forward to testing your “probable solution” when you have time to work on it.

I liked the why the Orb worked on my desk top and games menu as a mouse, it was fun just seeing what it would do.

After you explained how the key presses work (spin at the same rate) I now understand what I done wrong...I think?

Not really a question of you doing something wrong (you were doing it right as far as what you were doing)--just that the game anticipates people being able to do fine-grained turning control with the mouse, so the keyboard buttons for yaw/pitch are FAST to (for example) turn around corners quickly etc. Which is OK for movement if you have the mouse available but WAY too fast to just play with keyboard. Movement (WASD) feels more natural than turning with axis bindings partially because pretty much everyone moves with keypresses so the game is calibrated "correctly" there.

So I think in general with FPS games that don't support joysticks, we will find ourselves binding pitch/yaw to mouse axes and keyboard movement to translation axes.

I may have some free time today to try smoothing it out, and maybe to put in a better movement "map" for WASD.