Sorry for posting in Lounge, but I don't know of any better forum to ask about this kind of thing. Any better suggestions?
A project I work on involves simulating a proprietary medical device. It's got boxes that can slide in/out, knobs that turn, etc. What we want is to build a PC input device which simulates this. The real device is 100% mechanical but we think the housing is large enough to use to hold any electronics, actuators and what-not.
Does anyone have any experience in this area? My initial thought was we want it to show up as a standard game device, so that we can avoid writing custom drivers, which would be a pain. Does that make sense? Or perhaps there's some standard USB protocol to achieve a similar kind of thing.
Maybe I'm not explaining too well since I don't really know how to start, but basically we want a bespoke controller with a bunch of knobs and levers, that can be plugged into a PC without us needing to write a custom device driver.
We're probably going to use a factory to produce a bunch of these, it's how the electronics and software interface that is my area of interest. I know back in the day, people used to create their own serial-port interfaces but with USB and modern standards for input devices I have literally zero information on which to draw!
Thanks!
Building a bespoke PC input device
www.simulatedmedicine.com - medical simulation software
Looking to find experienced Ogre & shader developers/artists. PM me or contact through website with a contact email address if interested.
How about starting off with hobby robotics things?
Eg; http://www.trossenrobotics.com/Phidgets.aspx
When you know it all works and the software's done, it should be reasonably easy to go to an outsourced electronics design house and have them make a manufacturable version.
You may still end up needing to write some lower level code, but once the info is arriving at a USB port, it's pretty easy. In Linux you can even do this in userspace now and never have to mess with kernel stuff; you just include the usb library, open your device and you can read/write blocks of data to it.
Hobby robotics kits probably come with basic comms stuff implemented for windows anyway.
Eg; http://www.trossenrobotics.com/Phidgets.aspx
When you know it all works and the software's done, it should be reasonably easy to go to an outsourced electronics design house and have them make a manufacturable version.
You may still end up needing to write some lower level code, but once the info is arriving at a USB port, it's pretty easy. In Linux you can even do this in userspace now and never have to mess with kernel stuff; you just include the usb library, open your device and you can read/write blocks of data to it.
Hobby robotics kits probably come with basic comms stuff implemented for windows anyway.
It depends upon your precise requirements, but an Arduino board may do what you need. They've got an AVR microcontroller on board which can be programmed in C. There's a range of boards with different numbers of digital and analogue I/O pins. Communication is done via serial over USB, though it appears that latest revision of the boards have a seperate AVR microcontroller which deal with this serial <-> USB connection and you can reprogram them if you don't want to use USB serial as a communication mechanism. However I would recommend using serial as it's very easy to use, both on a hardware and software front, it's only unsuitable if you require lots of high speed data.
On the hardware setup I don't know how much say I've got, but both the replies so far, these are advocating a bespoke USB 'protocol', albeit a simple one? Is this preferable to hacking it to look like a standard gaming controller, each knob acting as an axis, etc...
To me that sounds easier because apart from anything else our software has to run on 32/64 bit versions of XP, Vista & W7.
But as I say I really don't know anything here... I just figured avoiding a bespoke driver would be better
To clarify, no part of the hardware stuff is being done by me, or my team. A separate company will be brought in, but I just want to know what I should ask them to do, or at least have an informed opinion before they suggest what they want... partially so I can check they know what they're talking about!
Does anyone know of a forum where this kind of thing might be most appropriate? Is there a relevant StackExchange site fr instance? Not that I'm saying GD can't help, I know there are people here with experience in many fields, but it is a bit specialised.
To me that sounds easier because apart from anything else our software has to run on 32/64 bit versions of XP, Vista & W7.
But as I say I really don't know anything here... I just figured avoiding a bespoke driver would be better
To clarify, no part of the hardware stuff is being done by me, or my team. A separate company will be brought in, but I just want to know what I should ask them to do, or at least have an informed opinion before they suggest what they want... partially so I can check they know what they're talking about!
Does anyone know of a forum where this kind of thing might be most appropriate? Is there a relevant StackExchange site fr instance? Not that I'm saying GD can't help, I know there are people here with experience in many fields, but it is a bit specialised.
www.simulatedmedicine.com - medical simulation software
Looking to find experienced Ogre & shader developers/artists. PM me or contact through website with a contact email address if interested.
Quote: but both the replies so far, these are advocating a bespoke USB 'protocol', albeit a simple one?
I was saying you could use a serial over USB protocol. Here the USB drivers have been written for you, and you would have to write a protocol on top of that that runs over serial. However this would all be handled by your app and would be very simple. It could be as simple as each different input having a state which you can encode as a byte, reserve 255 or 0 as a special value. Then the hardware would simply send 255[state1][state2][state3]...[staten]255[state1][state2][state3]... and so on continuously. Accessing a serial port is easy, FTDI who make usb <-> serial chips provide drivers for windows (and other OSes).
You could go the pretending to be a gamepad route, but frankly I imagine a custom protocol over a usb serial port is an easier option. Plus gamepads may have annoying limits on how many buttons and range of analogue motion that could restrict you.
Quote: Original post by JDX_JohnIn that case it should use the same protocol original device uses.
A project I work on involves simulating a proprietary medical device.
The point of simulator is to walk, talk and quack like the original thing.
Quote: I know back in the day, people used to create their own serial-port interfacesThey are still widely used. And they are as much pain as always, especially since these ports are rarely included in PCs anymore, so they use USB adapters.
As I said, the real device is 100% mechanical. Cogs, wires, etc - no electronics whatsoever. How realistic it looks and feels isn't my area, though using real parts seems feasible, but the electronics is purely about reporting the state of each knob, lever, etc accurately.
www.simulatedmedicine.com - medical simulation software
Looking to find experienced Ogre & shader developers/artists. PM me or contact through website with a contact email address if interested.
It's relatively straightforwards to implement a USB HID using V-USB and an AVR microcontroller of some description (depending on the number of inputs you require). You don't have to write a driver on the PC side; for something that has analogue inputs (knobs and sliders, for example) you could make your device show up as a joystick. The V-USB USB HID demo project is for a keyboard, and here's an example project that implements a joystick.
[Website] [+++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement