The ultimate orb solution, at last.

[vputz]

Digikey now has a USA location (Minnesota) so you don’t have to pay international shipping.

Other way round--I'm in the UK (grin). But good luck; I got quite a charge out of etching my own board. Hopefully it will work just fine for you. I think you won't have much trouble with the USB socket and dip switch; the spacing on those is pretty standard. The DB9 can vary I think, but I *think* it'll be ok.

I'm working the software end today; minor tweaks to handle spaceball packets. With luck it will all go well and I will be happy with design and ready to press on.

[vputz]

Okay, maybe it won't turn out to be the ULTIMATE orb solution, but we're getting there...

Here's a control system for you:



Left hand Spaceball 4000FLX, right hand mouse. Could this control system be entirely constructed any more of pure distilled win? Well, actually jury's still out a bit, but it's looking very good.

The good news: the Spaceball 3003 and 4000FLX work with the adapter (I was able to play through a level of L4D using it, which is now my "acid test"). This, by the way, has a LOT of promise; the 12 buttons on the spaceball plus the mouse buttons means you have more controls available, which is good, and the mouse for fine-grained control means you can get orblike movement for moving around combined with fine-grained aiming for shooting. The Z axis for jumping and crouching may not turn out to be the best idea, but it sorta works. I wind up kneeling accidentally a lot.

It is pretty darn wobbly! And there's a "feel" issue I don't know how to describe with the rotation, which may just have to be played with. Right now the HID reports we construct say the axis goes from 0 to 1023, but the spaceball has a much larger range than the spaceorb, so I have to do some scaling. The weird part is the range is almost asymmetric (ie something like -8000 to 12000 or bizarre ranges). In practice this may not be a problem as we can clip the limits, but it does bring me to the bad news:

1) (software) I'm not sure we can do the old "curve" sensitivity thing. The Arduino is severely limited with regard to memory; you can cheat by putting things in flash, but you have to page them out (I didn't know this) which may be too slow. This may or may not be a problem as I think we can do all the scaling at run-time.

2) (hardware, could be a problem) occasionally the adapter misses a byte. If the spaceball is sending a bunch of zeros, it just occasionally misses one, which was a real surprise until I figured it out (spontaneously an axis would go to max and random buttons would press. Hurray!). I've taken the approach "well, if the packet ends early and I don't have enough characters, it's a bad packet and we just don't process it" which seems to be working OK and it's quite usable. However, because it shook my faith a bit, I am going to take just a little more time on the Arduino forum checking to see if this is a fault of the Arduino, my circuit, or the orb. I think the circuit will work OK as it is, but I want to make extra sure I'm not missing something obvious to other people.

3) (Minor) : right now the spaceball does not automatically initialize at startup (I don't think I can). It waits until the first press of button #1. Well, that's not so bad.

I'm not crazy about the amount of source code editing I'm doing for configuration, so there may be some cleaning to do, but this is certainly encouraging. And I think I really like the 4000 as a gaming device once I get the sensitivity and "feel" issues down. Don't make a mad rush to ebay in case this doesn't work out, but I think it has a lot of promise (and heck, if you see one for really cheap...).

So it may not be the ULTIMATE orb solution, but it's a pretty good step (and it must be said that I don't think any of these problems apply to the SpaceOrb proper except the sensitivity curve, which I may be able to work around).

-->VPutz

[vputz]

Well, I posted my "drops multiple zero packets" problem on the Arduino forums, and evidently that's just a problem with long strings of null values in serial communications, since the line goes quiet except for the stop bit, so unless timing is really really tight the receiver just sees a "1" popping up out of nowhere and doesn't know if it's in the middle of a byte or what. Evidently the timing is juuuust off a widgy bit, and there's really nothing to do in hardware (certainly not in this sort of hardware).

So my current solution of dropping packets that look invalid looks like the right one. I played more L4D this morning and played with sensitivity and it feels better. Given that I haven't NEEDED any of the other DIP switch parts, or buttons, or LEDs, I'm inclined to drop the DIP package from 6 to 2, set everything in software upload, tidy up traces, make the design two-sided, and ship it. Any last calls for hardware features, or should we press on?

[TurtleMan]

I'm impressed with your rate of progress: guess I need to check in more often now- (two or three time a year used to be sufficient!). And that's quite some controller in the pic: do you work the buttons with your toes? As for your question, I have no inspiration regarding the feature set. I'll mention that I never experimented with the sensitivity curves: just left it on default with the commercial driver and Jay's version. So I'll never know the difference if you decide to omit them.

In general, with most things in life, I prefer simplicity: if I were in your position I'd streamline the hardware as much as possible. Simpler (usually) results in fewer failure modes. Likely cheaper and easier to build, too. I'll be happy if all of the axes and buttons work smoothly, and maybe some small ability to tweak the response speed (analogous to "Mouse sensitivity" setting found in most FPS's).

take it easy,

turtleman

[vputz]

that's quite some controller in the pic: do you work the buttons with your toes?

Heh... good old Spacetec... they only gave us the SpaceOrb for games, preferring to keep the sexy desk-mounted devices for the CAD purists. Not any more!

I'm impressed with your rate of progress: guess I need to check in more often now- (two or three time a year used to be sufficient!).

You think that's good; my spaceball said "hi" to me tonight.

Actually, it said "hhii", but let me tell you that's a good deal better than "hhhhhhhhiiiiiiiiiiiihhhhhhhhhhhiiiiiiiiiiiii" which is what it was doing until I figured out how to get it to STOP sending keyboard reports. Now it sends one letter with each press and release, and that's not what I think I want it to be doing.

...which, if you read that too fast, means that it can now send joystick AND keyboard events. Mouse to come soon once I figure out joystick and get a good binding interface. I'm not really sure I know why it should send keyboard events, but I think it's important that it can.

(actually, you could set up a complicated "if the X axis is pushed this far to the left, hold down the 'A' key" for WASD mappings, but really if you can't get the axis range, why use the orb--and if you CAN get the axis range, your game accepts joystick input and you shouldn't need to map keyboard events to it, but one irrational use at a time, please)

(Actually, there could very well be a use, since shortly we will be able to bind axes to mouse events, so you could use the orb for games that don't support joysticks, even though the orbness of it would be mostly for looking around).

I have another confession to make: the Arduino is probably the "wrong" hardware to use for this, because we have to hack on our own USB connector and bit-bang the USB lines. The "correct" way of doing this would be to use one of the Atmega AT90USB chips in a package like the avropendous or teensyduino. And there's something to be said for that, because using one of those would make the board a lot simpler (half the circuit would vanish, leaving almost nothing but the MAX233 chip and the RS232 plug), it would be a bit cheaper, and the USB side of things would be more proper. Occasionally I feel guilty about using the wrong hardware and think about redesigning the whole thing.

But in the end I think Arduino is probably the right thing to do because 1) this works, and 2) the easy of programming and updating the thing will be there, and I really want folks to feel comfortable programming their orbs (instead of config files for games, you will be uploading little programs to your OrbDuino). Without that the programming user-end of things will be a bit trickier--not badly, but enough to make me concerned. If anyone is really going to be a hardware purist and want to use an AT90USB, much of the "driver" will be very portable to that.

But I should probably stop working on fun projects and get some stuff. Sleep, that's it (grin).

[RadioBozo]

ok, quick question, has anyone thought about using the analog inputs of the ATmel uController to read the optical sensors directly, and output a SpaceOrb360 compatible data stream, or a HID stream, up the USB port, bypassing the original transistors/chips on the original board? Without doing the serial to USB conversion? Just a thought. The wires from the Optical sensors go into what looks like buffer transistors, not sure, I'll have to draw out a schematic, does anyone have or has anyone traced the circuitry and drawn up a schematic? 360 specifically, not the later SpaceBalls.

[vputz]

RadioBozo:

Yes, I had that thought. I didn't go that route for two reasons: 1) I wasn't sure it would work and didn't want to muck with the hardware as I don't have spares, and 2) I figured most people weren't too keen on soldering at all so I wanted to keep it as simple as possible without having people break open their orbs (also leaves them working "as is" for other operating systems like Linux, etc). Additionally, the orb (and spaceballs) take some extra data (null region, time between button packets, in the case of the balls time between ball packets and bunches of other options like setting the sensitivity curves right in hardware) that you'd have to completely bypass and thus lose some capability. I also liked the idea of one device which (with a hardware swap) could do the serial-to-hid operation for a number of other legacy devices (like the whole spaceball family and other old weird devices).

I'm also not sure what data you get out of the sensors (ie how the sensor actually outputs its data). There's no real reason you couldn't do it, and for arguably a better product; I just liked the idea of an adaptor better than a permanent hack. I say give it a go and see what happens!

[vputz]

For silliness' sake...


Dropped the DIP switch from 6 positions to 2, moved a few things around, switched to 2-sided board, thinned traces. The Eagle3D script doesn't have parts for the zener diodes or USB B connector, which is why you just see the silkscreen, but I'm going to try to get this to manufacturing in the next couple days (I want to actually get the "orbduino.sourceforge.net" registered first).

Still have work to do on the software side (proper bindings for keyboard and mouse, and I may rearchitect things a bit) but it's looking good.

[countryatheart]

Your new PCB looks Great Victor! A lot better then the one I just etched and drilled tonight. I did have a lot of fun doing it. (Big Grin) I made a 2 sided board and it turned out ok for the first try. Here are a couple of pictures so you can see what your Orb PCB looks like when a drunken monkey and a cross eyed old fart does it.

Orb PCB Bottom.JPG (111.66 KiB) Viewed 102890 times

When you have the new Orb PCB’s manufactured please order 2 extra for me and I will pay you by PayPal or however you prefer.

Ron

[vputz]

Actually your two-sider looks a lot better than my one-sider with multicolored jumpers, that's for sure!

The real test is whether yours works or if I've got a design which is only working with my stuff (it's happened). Thanks for making one and testing it! I'm very curious to see what your results are. At this rate I will have to produce software faster!

[countryatheart]

Thanks Victor, I checked out the traces with a multimeter and all traces are intact and no shorts. I do have 1 set back, while checking the components for proper fit I discovered the IC socket pin layout .060 longer then the pin layout on the PCB. I am sure it is do to my freehand drilling. A drill press would be more actuate. The IC socket I ordered has rigid pins and I broke off 2 of the pins trying force the socket into the holes. I have to tweak the holes a bit and find a IC socket that has pin flexibly.

I also need to reorder a dip switch I never received that I have a question about. Your post on Jan. 10 has a picture of your PCB, it appears that all the dip switches are in the off position with the exception of #1 that is on. Is this correct? If it is could I replace the 6 position dip switch with a 2 position?

Ron

[vputz]

Yes--the new board design is in fact a two-position. We need two contacts because the serial lines double from the Arduino's USB-to-serial connection (for programming it) and for talking to the orb, so we need to be able to shut them "off" (ie only talking to the USB-to-serial) or turn them "on" (for talking to the orb)--so when uploading a new program you turn them off, load program, turn them on, unplug USB-to-serial (on the Arduino), plug in USB (on our board). For the SpaceOrb proper, you probably only need the switch on line 0, since right now we never send any information to the orb, just receive from it--the second one (on pin 1) is there for the spaceballs. You could use a jumper or something too--the DIP switch is just handier.

Bad luck on the IC socket. Hmm--it lined up fairly well for me but was pretty rigid and a tight fit. I'm a little concerned but hopefully it will work out.

Spent some time this weekend--keyboard-to-button binding is working flawlessly and some mechanism is in place for keyboard-to-axis-position (which honestly is probably not as useful as I thought it would be--was diverting to walk around in World of Warcraft using the orb for movement and turning, but didn't "feel" useful and I'd rather use the keyboard... but could be useful, say, to use the Z-axis for "jump/crouch" or something in games that otherwise support orb-like motion).

Programming the Arduino is giving me some challenges because you really don't have much RAM at all (1024 bytes, shared with stack!) and no real indication of how close you are. Plenty of code space for our purposes though... but occasionally I would call a function and the stack push would crash the thing with no warning. No recursion here! I still think I can wedge in the mouse bindings, though (which would be quite cool).

I'll try to get updated software up for you to try on the homemade board once you're up and running!

[countryatheart]

I really appreciate your help Victor. I now understand how this invention of yours works (I think) . After I complete fabricating my board I’ll let you know. I haven’t played any games for 2 or 3 years but I do have same old ones I can test it on.

I found the problem with the IC socket pin spacing. I printed out your Test 4 Bottom PDF and set the 20 pin IC socket on the schematic and the IC socket pins (only18 of them left) didn’t match, the spacing was off just as much as the board I made. I am guessing that saving your schematic to a PDF or my printer software distorted it a little. I ordered a 20 pin IC socket that has blades instead of rigid pins, I hope the blades will flex so they fit. If I can’t make the IC socket work I’ll modify your schematic and make another board.

Ron

[vputz]

Hmm, very interesting. It might be a scaling thing (PDF programs are bad about "print to fit"). I don't THINK this will be the case, but check the A4/Letter thing (I'm pretty sure it was letter, but since I am in the UK and ran into that problem...)

If you want to recreate it, try downloading the eagle files (the "orbshield.zip") and you can print your own PDF using Eagle (free download) and see if that works any better.

Sorry to hear the scaling was strange--your board sure looked great (better than mine). Guess it's a reminder to check fit on the paper before etching, but I would have made the same mistake if I hadn't had the letter/A4 problem. Good luck!

Also--not much there yet, but (sorry for the bad name, had to choose something): http://orbduino.sourceforge.net. I'll get the Eagle files and revised software up there soon for download, and eventually make a purty web page.

I still may eventually make a version of the back-end for an AVR USB chip, but so far I'm impressed by the Arduino's output...

[vputz]

Totally minor updates:

1) Order for 1 batch of the PCBs is in, should be a week or so--then we see if I've screwed something up with the redesign.

2) The AVR USB chips have half the SRAM of the Arduino, so I'm still happy with choice of platform (although I ordered one just to see).