Thread: [tuxdroid-user] Tuxdroid gamepad interface
Status: Beta
Brought to you by:
ks156
Menu
▾
▴
tux-droid-user
|
From: Bruno C. <bru...@fr...> - 2007-04-09 10:21:11
|
I got an idea yesterday, why don't we make tuxdroid be seen as a regular gamepad/joystick at the USB level. In the same spirit as having a regular sound card, makes it easy to use it's audio feature, using it as a regular gamepad would let integrator use it like any other gamepad. The 4 inputs would be the 2 wings, head and eye. Then using the force feedback API, we should be able to activate the actions, rotation, ... Have you already been that path, is this possible ? -- Bruno Coudoin http://gcompris.net Free educational software for kids http://toulibre.org Logiciel Libre à Toulouse |
|
From: Florent T. <ft...@gm...> - 2007-04-09 12:06:49
|
Sounds like a good idea to me ! Add to this the possibility to use the IR transceiver as if it was really on the host computer... But then there would be no need for the daemon anymore.... |
|
From: Philippe T. <ph...@te...> - 2007-04-09 17:26:26
|
Florent THIERY wrote: > Sounds like a good idea to me ! > > Add to this the possibility to use the IR transceiver as if it was > really on the host computer... > > But then there would be no need for the daemon anymore.... > Using the joypad API won't help that much I think. We have many inputs, not just 4: - wings & head - light level - IR codes - future: battery level Some of those inputs are on events, some are on polling (which could be also on events if there is a trigger level in the firmware such as low batt warning) We have many outputs, more than what feedback joystick API could offer - eyes, mouth, wings, spin movements - eyes leds, IR led We have still the major issue to be dealt by a daemon: allowing multiple applications to interact with the Tux. And having a "false" joystick being the Tux could make strange thinks with games using automatically any found joystick... Phil |
|
From: David B. <da...@ja...> - 2007-04-09 18:16:33
|
On Mon, 09 Apr 2007 19:26:15 +0200, Philippe Teuwen <ph...@te...> wrote: > Florent THIERY wrote: >> Sounds like a good idea to me ! >> >> Add to this the possibility to use the IR transceiver as if it was >> really on the host computer... >> >> But then there would be no need for the daemon anymore.... >> > Using the joypad API won't help that much I think. > We have many inputs, not just 4: > - wings & head > - light level > - IR codes > - future: battery level I would also like to add the noise level, a kind of peak microphone level that can be used to detect handclaps or someone that shouts or simply differentiate silence from noise. You could also detect if you try to manually close the eyes when they're opened but that's not reliable. (the 'eyes open' switch should be released but that's not sure it will be pushed again when you'll release the eyes) > Some of those inputs are on events, some are on polling (which could be > also on events if there is a trigger level in the firmware such as low > batt warning) > > We have many outputs, more than what feedback joystick API could offer > - eyes, mouth, wings, spin movements > - eyes leds, IR led > > We have still the major issue to be dealt by a daemon: allowing multiple > applications to interact with the Tux. > > And having a "false" joystick being the Tux could make strange thinks > with games using automatically any found joystick... > > Phil > I guess Bruno wants this to interact with simple games like GCompris. If you only need a few buttons, why not. You could have 2 modes, one with the 2 wings and head button, and anoher mode using the remote keys. Forcing the eyes should be used carefully (see above) and forcing anything else will not work because of the clutch (spin or wings) or will be difficult (beak). One could use the light sensor to detect when the hand covers the eyes for example, but you should take care of all different situations where the luminosity will vary. There're different ways to get that funcitonality: - a specific USB firmware that could be recognized as a joystick, seems hard to develop as you need some 8051 and USB knowledge and kysoh/c2me probably won't have the ressources to develop that atm; - a virtual jostick driver, I guess this should be possible but I've no experience; - using plugins and the api, which is what we want to do now as you can have much more than a joystick functionality but you will have to implement that for any application. If the second option is easy to develop, why not. But is there many applications that will benefit from this? As we use the RF, there's a reaction time which is not negligible and will make mmost of the games unusable. Jst my 2 cents david |
|
From: Bruno C. <bru...@fr...> - 2007-04-09 19:08:23
|
Le lundi 09 avril 2007 à 14:06 +0200, Florent THIERY a écrit : > Sounds like a good idea to me ! > > Add to this the possibility to use the IR transceiver as if it was > really on the host computer... True, using the same strategy, it should be seen as a regular IR transceiver so that all existing application based on that protocol can be used with Tuxdroid without changing them. -- Bruno Coudoin http://gcompris.net Free educational software for kids http://toulibre.org Logiciel Libre à Toulouse |
|
From: Bruno C. <bru...@fr...> - 2007-04-09 21:07:36
|
Le lundi 09 avril 2007 à 19:26 +0200, Philippe Teuwen a écrit : > Florent THIERY wrote: > > Sounds like a good idea to me ! > > > > Add to this the possibility to use the IR transceiver as if it was > > really on the host computer... > > > > But then there would be no need for the daemon anymore.... > > > Using the joypad API won't help that much I think. > We have many inputs, not just 4: Well there are joypads up to 10 inputs as far as I saw. > - wings & head Can be mapped to button > - light level > future: battery level Can be mapped to 2 analogs axis > - IR codes Should use the GNU/Linux IR API (don't know it). > Some of those inputs are on events, some are on polling (which could be > also on events if there is a trigger level in the firmware such as low > batt warning) Like I said, low batt can be an analog axis, for the rest, using the force feedback API, it should be possible to set trigger levels if needed. > We have many outputs, more than what feedback joystick API could offer > - eyes, mouth, wings, spin movements > - eyes leds, IR led I have not seen the force feedback API, this needs investigations. > We have still the major issue to be dealt by a daemon: allowing multiple > applications to interact with the Tux. Having a clean standard way to access the daemon does not preclude you from making a daemon on top of it for this need. The daemon way implies a much more complex / specific integration with each applications but I don't see what it means for having several applications waiting for a tux button, which one must make the action, both, ... For the IR function, I already played with LIRC that does the application sharing, each IR code can send specific X events to any applications. It would be easy just to create lirc config files for gnome, kde, ... > And having a "false" joystick being the Tux could make strange thinks > with games using automatically any found joystick... Well, I saw vlc for example, it let you specify you /dev joystick interface to use. But frankly, it's not tuxdroid problem and the user can simply unplug fux. Just checking supertux --help we have: -j, --joystick NUM Use joystick NUM (default: 0) --joymap XAXIS:YAXIS:A:B:START Clearly, more i dig into it, more I believe it's a natural path to go through the standard API, it has some drawbacks but the benefits are huge. -- Bruno Coudoin http://gcompris.net Free educational software for kids http://toulibre.org Logiciel Libre à Toulouse |
|
From: Florent T. <ft...@gm...> - 2007-04-10 07:52:45
|
> Just checking supertux --help we have: > -j, --joystick NUM Use joystick NUM (default: 0) > --joymap XAXIS:YAXIS:A:B:START LOL. Playing supertux using a real tux controller, that would be a MUST :) |
|
From: Philippe T. <ph...@te...> - 2007-04-09 22:51:45
|
>> - light level >> future: battery level >> > Can be mapped to 2 analogs axis > > So the idea is to use an existing API but with such a mapping you could hardly use it with anything else than the daemon. Mapping the three buttons to joystick buttons allow basic control of other softwares expecting a joypad but mapping light level and battery level to analog axis make the tux hardly usable as a joypad! Shortly said: I don't see the benefit of mapping to an existing API if the result could be used anyway only by the daemon or tux-specific programs. >> - IR codes >> > > Should use the GNU/Linux IR API (don't know it). > I agree we could beneficiate from a separate API for the IR part. I had a look to LIRC but it looks like there isn't much of common API here. And we get directly RC5 codes while usually LIRC gets more raw data and is therefore capable to understand a larger set of remote controls. But we definitively need to find a way to hook the tuxdroid to lirc! Note that looking to the firmware gives me the confidence the tuxdroid could also receive more than just RC5 codes and the firmware could be as smart as lirc to decode a variety of rc or pipe raw IR data to lirc. > Well, I saw vlc for example, it let you specify you /dev joystick > interface to use. But frankly, it's not tuxdroid problem and the user > can simply unplug fux. > If you plug sth pretending to be a joypad but acting as a mad joypad, it's a tuxdroid problem :-) Looks like I still need to be convinced ;-) Maybe getting the 3 button events mapped to a USB mouse could help (but no movements) so applications controlled by mouse buttons (diaporama, ooimpress,...) can be controlled by the tux. Phil |
|
From: Bruno C. <bru...@fr...> - 2007-04-09 23:58:38
|
Philippe Teuwen a écrit : >>> - light level >>> future: battery level >>> >> Can be mapped to 2 analogs axis >> >> > So the idea is to use an existing API but with such a mapping > you could hardly use it with anything else than the daemon. > Mapping the three buttons to joystick buttons allow basic control > of other softwares expecting a joypad but mapping light level > and battery level to analog axis make the tux hardly usable > as a joypad! True, the analog part is really borderline, it's still a good compromise in my opinion. Looking at GCompris, if I want to use the light level, it's clearly easier for me to use the joystick api for that than having to support gamepad for buttons and using another API for the light. I could as well detect the gamepad name as being a tuxdroid and have some specific code for it. > Shortly said: I don't see the benefit of mapping to an existing API > if the result could be used anyway only by the daemon > or tux-specific programs. That's not true, in GCompris case, if we add basic gamepad support, it will work with tuxdroid and regular gamepads, modulo the analog part which is borderline but for which the use case is not evident for GCompris anyway. If you believe analog mapping is a bad idea, just don't implement it and just provide the buttons. > > Maybe getting the 3 button events mapped to a USB mouse could help > (but no movements) so applications controlled by mouse buttons > (diaporama, ooimpress,...) can be controlled by the tux. > That would even be easier for me. Hum, in fact no, there is a focus issue. Will work in diaporama but nothing more. In GCompris, I receive click events only when you click on an item that expects it. I can return you your remark: If you plug sth pretending to be a joypad^W mouse but acting as a mad^Wbroken mouse, it's a tuxdroid problem ;) |
|
From: David B. <da...@ja...> - 2007-04-10 06:40:05
|
On Tue, 10 Apr 2007 00:51:34 +0200, Philippe Teuwen <ph...@te...> wrote: >>> - IR codes >>> >> >> Should use the GNU/Linux IR API (don't know it). >> > I agree we could beneficiate from a separate API for the IR part. > I had a look to LIRC but it looks like there isn't much of common API > here. > And we get directly RC5 codes while usually LIRC gets more raw data > and is therefore capable to understand a larger set of remote controls. > But we definitively need to find a way to hook the tuxdroid to lirc! > Note that looking to the firmware gives me the confidence the tuxdroid > could > also receive more than just RC5 codes and the firmware could be as smart > as lirc to decode a variety of rc or pipe raw IR data to lirc. > The firmware currently decodes the RC5 protocol. Out of this, only the command is sent back to the computer, the address is not but that shouldn't be a problem to send it too. The advantage of decoding directly is to get a single byte out of the IR event and be able to handle it locally like in the remote mode. I planned to change this by a universal emitter/receiver where the IR signal would be sampled much more quickly and the raw code would be compressed (optioanl) and sent to the computer for decoding. There are numerous application notes describing this for various microcontrollers. I think it would be better to mimic what some of the already existing homemade IR peripherals do as we could benefit from its LIRC driver without much modifications. The only problem I see is the RF bandwidth, for commands we can send 4 bytes each 2 ms maximum but I believe the current spi protocol between the audio CPU and the RF only allows 4 bytes each 4ms (tbc). We need the first byte for the command identification, the second byte for the index and the last 2 bytes for the data, which means it will take a lot of time to send a raw code to the computer. That's one part of the RF protocol I didn't like from the beginning. All frames holds 64 bytes or so which most of them are just audio data, leaving only 4 bytes for commands. This is fine in most cases but I would have preferred to have different kind of frames, some of which could be data only in order to have a much bigger data bandwidth. david |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X