tux-droid-user — tuxdroid-user

Re: [tuxdroid-user] Event handling chain?

[Martin T. <ma...@ma...>]

On Tue, 2007-04-10 at 08:57 +0200, David Bourgeois wrote:
> On Mon, 09 Apr 2007 23:55:23 +0200, martin <ma...@ma...> wrote:
> 
> > Are button presses (like wing or head or RC) always passed on by the
> > firmware or can they be 'swallowed'?
> >
> > I am thinking of adding a function to the firmware so that I can tap the
> > head button to mute sound.. but I am not sure if the button event will  
> > still
> > be propagated to the daemon, overloading the button.  Maybe I could just  
> > do
> > everything on the pc.. but I would like to play with the firmware a  
> > little
> > more.
> 
> That depends on what you want to handle locally and from the computer. I  
> would say that muting the sound requires to have sound sent from the  
> computer so I would find it more logical to have the computer get the head  
> button event and decide to do the mute (by siftware or send the mute  
> command). But in case you just use the usb audio device and don't have the  
> daemon running, that makes sense to have it locally by firmware.
You might also want to mute locally stored sounds which Tux will play
regardless of a host computer. So perhaps a mute button is not as simple
as it appears.
> 
> In such a case, I think the standalone behavior proposal I already  
> explained a bit would be a good solution. You could associate the mute  
> function to the head button event in the eeprom (when this will be  
> possible to do from the api in the near future) and easily enable/disable  
> that event from the computer. When disabled,the status of the button would  
> still be sent to the computer but the sequence won't be played. So even if  
> your applications need to use the head button at a certain point, they  
> could still disable the standalone head button event momentarily. Though  
> the daemon/api should handle that instead of the application.
It probably is an application level behaviour to associate buttons and
behaviours.
> 
//m

Re: [tuxdroid-user] Tuxdroid gamepad interface

[Florent T. <ft...@gm...>]

> 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 :)

Re: [tuxdroid-user] fuxusb sources?

[David B. <da...@ja...>]

On Tue, 10 Apr 2007 02:15:05 +0200, Philippe Teuwen <ph...@te...>  
wrote:

> aplay -l|grep card
> card 0: ICH6 [Intel ICH6], device 0: Intel ICH [Intel ICH6]
> card 0: ICH6 [Intel ICH6], device 4: Intel ICH - IEC958 [Intel ICH6 -
> IEC958]
> card 1: Modem [Intel ICH6 Modem], device 0: Intel ICH - Modem [Intel
> ICH6 Modem - Modem]
> card 2: default [TUX RF DONGLE ], device 0: USB Audio [USB Audio]
> card 2: default [TUX RF DONGLE ], device 1: USB Audio [USB Audio #1]
>
> There is an extra space at the end of the id string I wanted to remove
> but the fuxusb sources are not on svn.
> Are they available?
>
> Phil

No they're not at the moment, the main reason is that they're for a 8051  
based CPU so you can't use GCC to compile it. We used the compiler of Keil  
under windows to develop it. I guess there should be some free compiler  
under linux but I only had a slight look once and didn't find anything  
relevant. There's even not a lot of ressources for the 8051 though that  
CPU has been there for ages and is still widely used. When you see how  
great avr-libc and the avrfreaks community are, I just can't stand using  
the 8051 anymore.

I lately made an update of the fux firmware to change the product and  
manufacturer usb names to "Tux Droid" and "Kysoh".
That should remove the extra space :-) (hex file attached)

david

Re: [tuxdroid-user] IR question

[David B. <da...@ja...>]

On Tue, 10 Apr 2007 01:08:52 +0200, Philippe Teuwen <ph...@te...>  
wrote:

> Hi,
>
> I try to understand how IR reception works.
> If I use the kysoh remote control, the tux gets the signals
> and its eyes blink as confirmation.
> It looks like, from the fw, any RC5 code would be accepted.
> But I tried with my tv and tv remote.
> The tux can control the tv, so sending RC5 commands.
> But my tv remote seems to not be understood by the tux,
> no led blinking :-(
>
> But in the fw I didn't see any check on the RC5 address before
> the led blink feedback so what does it means?
> The tux doesn't see my tv remote at all?

Indeed I don't check the address, you can use any RC5 code but at the  
moment only the command is sent back in the status iirc. That should be no  
problem to send the address too.

So if your remote is RC5, it should be seen by tux. I don't know why it  
doesn't, would need to have your remote to debug that. I have a KISS DVD  
remote control that mixes RC5 and other protocol keys (weird) but the RC5  
keys work just fine.

>
> Another question:
> RC5 greeting codes are:
> addr 0x4 + command random (light level sampling)
> addr 0x8 + command random (light level sampling)
> addr 0xC + command random (light level sampling)
>
> But couldn't they have bad effects on the devices mapped to those  
> addresses?
> addr 0x4 is a Laser Vision Player (?)
> addr 0x8 is Sat1, a settopbox I assume
> addr 0xC is a CD-Video
> We could take some reserved addresses instead: 7, B, D, F, 18, 19, 1B-1F

That code is to be removed or corrected. At a certain point in  
development, it somehow worked and 2 tuxs could see each other and do some  
greetings, but that doesn't work well anymore and this functionality  
should be implemented in another way. That was just a quick draft at that  
time and I never had the opportunity to rework it.

But to answer your questions, I used the address as a command and the  
random number as a tux identifier. And that indeed could clash with your  
equipment though the probability is quite low. We can change to reserved  
adresses anyway.

> And what is the addr code sent by the Kysoh remote?

It's 0x1D

david

Re: [tuxdroid-user] Event handling chain?

[David B. <da...@ja...>]

On Mon, 09 Apr 2007 23:55:23 +0200, martin <ma...@ma...> wrote:

> Are button presses (like wing or head or RC) always passed on by the
> firmware or can they be 'swallowed'?
>
> I am thinking of adding a function to the firmware so that I can tap the
> head button to mute sound.. but I am not sure if the button event will  
> still
> be propagated to the daemon, overloading the button.  Maybe I could just  
> do
> everything on the pc.. but I would like to play with the firmware a  
> little
> more.

That depends on what you want to handle locally and from the computer. I  
would say that muting the sound requires to have sound sent from the  
computer so I would find it more logical to have the computer get the head  
button event and decide to do the mute (by siftware or send the mute  
command). But in case you just use the usb audio device and don't have the  
daemon running, that makes sense to have it locally by firmware.

In such a case, I think the standalone behavior proposal I already  
explained a bit would be a good solution. You could associate the mute  
function to the head button event in the eeprom (when this will be  
possible to do from the api in the near future) and easily enable/disable  
that event from the computer. When disabled,the status of the button would  
still be sent to the computer but the sequence won't be played. So even if  
your applications need to use the head button at a certain point, they  
could still disable the standalone head button event momentarily. Though  
the daemon/api should handle that instead of the application.

david

Re: [tuxdroid-user] Tuxdroid gamepad interface

[David B. <da...@ja...>]

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

[tuxdroid-user] fuxusb sources?

[Philippe T. <ph...@te...>]

aplay -l|grep card
card 0: ICH6 [Intel ICH6], device 0: Intel ICH [Intel ICH6]
card 0: ICH6 [Intel ICH6], device 4: Intel ICH - IEC958 [Intel ICH6 - 
IEC958]
card 1: Modem [Intel ICH6 Modem], device 0: Intel ICH - Modem [Intel 
ICH6 Modem - Modem]
card 2: default [TUX RF DONGLE ], device 0: USB Audio [USB Audio]
card 2: default [TUX RF DONGLE ], device 1: USB Audio [USB Audio #1]

There is an extra space at the end of the id string I wanted to remove 
but the fuxusb sources are not on svn.
Are they available?

Phil

Re: [tuxdroid-user] Tuxdroid gamepad interface

[Bruno C. <bru...@fr...>]

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 ;)

[tuxdroid-user] IR question

[Philippe T. <ph...@te...>]

Hi,

I try to understand how IR reception works.
If I use the kysoh remote control, the tux gets the signals
and its eyes blink as confirmation.
It looks like, from the fw, any RC5 code would be accepted.
But I tried with my tv and tv remote.
The tux can control the tv, so sending RC5 commands.
But my tv remote seems to not be understood by the tux,
no led blinking :-(

But in the fw I didn't see any check on the RC5 address before
the led blink feedback so what does it means?
The tux doesn't see my tv remote at all?

Another question:
RC5 greeting codes are:
addr 0x4 + command random (light level sampling)
addr 0x8 + command random (light level sampling)
addr 0xC + command random (light level sampling)

But couldn't they have bad effects on the devices mapped to those addresses?
addr 0x4 is a Laser Vision Player (?)
addr 0x8 is Sat1, a settopbox I assume
addr 0xC is a CD-Video
We could take some reserved addresses instead: 7, B, D, F, 18, 19, 1B-1F

And what is the addr code sent by the Kysoh remote?

Phil

Re: [tuxdroid-user] Tuxdroid gamepad interface

[Philippe T. <ph...@te...>]

>> - 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

Re: [tuxdroid-user] Python script for remote control

[Florent T. <ft...@gm...>]

YEssss

Thx for the sample code, it will sure help !

[tuxdroid-user] Event handling chain?

[martin <ma...@ma...>]

Are button presses (like wing or head or RC) always passed on by the 
firmware or can they be 'swallowed'? 

I am thinking of adding a function to the firmware so that I can tap the 
head button to mute sound.. but I am not sure if the button event will still 
be propagated to the daemon, overloading the button.  Maybe I could just do 
everything on the pc.. but I would like to play with the firmware a little 
more. 

Thanks // Martin

Re: [tuxdroid-user] Tuxdroid gamepad interface

[Bruno C. <bru...@fr...>]

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

Re: [tuxdroid-user] Tuxdroid gamepad interface

[Bruno C. <bru...@fr...>]

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

Re: [tuxdroid-user] Tuxdroid gamepad interface

[David B. <da...@ja...>]

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

Re: [tuxdroid-user] Tuxdroid gamepad interface

[Philippe T. <ph...@te...>]

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

Re: [tuxdroid-user] Tuxdroid gamepad interface

[Florent T. <ft...@gm...>]

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....

[tuxdroid-user] Tuxdroid gamepad interface

[Bruno C. <bru...@fr...>]

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

[tuxdroid-user] Python script for remote control

[Martin T. <ma...@ma...>]

Here's a little python script to read the key presses from the remote =20
and perform some action. I wrote it a couple of days ago before I dove =20
into the firmware.

Push the red button and tux reads a canned weather report.
Push the blue button and he offers a number guessing game.
Push yellow to quit.

//m


#!/usr/bin/python
# -*- coding: latin-1 -*-
## Borrowed tux.py and added some extra stuff..

import sys
import sys
sys.path.append('/opt/tuxdroid/api/python')

from tuxapi_const import *
import tuxapi_class
import tuxapi_wav_merger
import signal
import time

global tux

run_state=3D1
tux=3Dtuxapi_class.TUXTCPCommunicator(5000, "localhost")
tux.print_api_version()
wavs=3Dtuxapi_wav_merger.WavMerger(tux)
tux.connect_to_daemon()

def exit(signum,frame):
     print "exiting (%d) ..."%(signum)
     tux.disconnect_from_daemon()
     sys.exit(signum)

signal.signal(signal.SIGTERM, exit)
signal.signal(signal.SIGINT, exit)

print "Remote control demo"

def weather():
     weather =3D open('weather.rep').read()
     tux.tts.speak_free(weather)

def my_exit():
     print "Leaving now.."
     tux.disconnect_from_daemon()
     global run_state
     run_state=3D0
     print "Run state =3D %s"%run_state
     sys.exit(0)

def game():
     import random
     tux.tts.speak("Guess what number I am thinking of  ! Press a =20
number key to play or press e
sc to quit !")
     my_number =3D random.randrange(0,9)
     tux.tts.speak("Here's a clue, it's %s.."%my_number)
     while(tux.explicit_status()<>'IR code->K_ESCAPE' and =20
tux.explicit_status()<>'IR code->K_%s
'%my_number):
         print "Status: ", tux.explicit_status()
         pass
     if tux.explicit_status()<>'IR code->K_ESCAPE':
         tux.tts.speak('Congratulations! You got the number!')


tux.event.set_on_remote_bt(K_RED, weather)
tux.event.set_on_remote_bt(K_BLUE, game)
tux.event.set_on_remote_bt(K_YELLOW, my_exit)

while run_state:
     time.sleep(0.01)
     pass

[tuxdroid-user] Extended remote control standalone functionality

[Martin T. <ma...@ma...>]

I was showing off my tuxdroid at the Dallas area unix group and I =20
realised that there was no function to play sounds so I went browsing =20
in the firmware source code.  The patches are attached.

See =20
http://www.tuxisalive.com/documentation/how-to/remote-control-standaloneby =
=20
just pushing buttons (no computer or dongle involved).

I decided that the colour keys would be suitable and tried a stored =20
sound to each one and ended up assigning a behaviour (like when you =20
connect the power or turn tux on).

In the tuxcore code, the file standalone.c contains a switch statement  =20
that describes what should happen when the remote sends a key press. It =20
looks like this:

switch (ir_command)
{
   case K_0:
     COMMAND;

     break;
}

with a case for each key code.
So I added cases for K_RED, K_GREEN, K_BLUE and K_YELLOW, something =20
like this:

case K_RED:
   launchActions((const uint8_t*)&tux_k_red_e);
   break;

tux_k_red_e describes what should happen when the red button key code =20
is received. There is one for each key.

In config.c, I added an entry for tux_k_red_e:
uint8_t tux_k_red_e[LONG_EVENT] EEMEM =3D TUX_K_RED_E_SEQ;

and in common/config.h, I added a description of the sequence:
/* Actions on Red Button */
#define TUX_K_RED_E_SEQ {\
     10, PLAY_SOUND_CMD, 3, 0, 0, /* play a sound */\
     10, MOVE_MOUTH_CMD, 2, 0, 0,\
     END_OF_ACTIONS\
}
The number after the sound cmd is the index of the stored sound to be =20
played. I don't know what the number at the start of each line is for.

A few lines need to be added to the config.h in tuxcore (not the one in =20
common/):
/* Demo sequences on remote colour keys */
extern uint8_t tux_k_red_e[];

After I compile everything, upload it to the tux and try it out, I find =20
it mostly works.  For some reason, even though all the behaviour =20
sequences look alike except for the sound number, Tux doesn't always =20
want to play when the red button is pressed, but works on the other =20
keys.  Also, the eyes don't light when Tux is powered on and he makes =20
no noise.

Another oddity is that the mouth movements and wing flappings occur at =20
different times for each colour, but occur consistently at those times.

I have attached patches in case they are of interest:
demo_h.patch - patches config.h.
demo.patch - patches common/config.h
demo_c.patch - patches config.c and standalone.c - if this patch is not =20
applied, the patches to the .h files have no effect.

Cheerio // Martin

Re: [tuxdroid-user] Problem during installing TuxUp-1.1.0

[David B. <da...@ja...>]

On Fri, 06 Apr 2007 17:15:08 +0200, Stefan Puchmann  
<ste...@fh...> wrote:

> Hi @ all,
>
> i have tried to follow the how-to
> (http://www.tuxisalive.com/documentation/how-to/updating-the-firmware)
> to upgrade the firmware of my tux-droid.
>
> I have successfully installed dfu-programmer-0.4.0 but I'm getting an
> error when I'm executing the make command from tuxup:
>
> root@redeagle-laptop:/home/redeagle/download/tuxup-0.1.1# make
> gcc -lusb -g -Wall -o tuxup main.c bootloader.c usb-connection.c
> main.c: In function ‘check_hex_file’:
> main.c:194: error: ‘version_t’ has no member named ‘cpu_nbr’
> main.c:195: error: ‘version_t’ has no member named ‘ver_major’
> main.c: In function ‘prog_flash’:
> main.c:220: error: ‘version_t’ has no member named ‘cpu_nbr’
> main.c:225: error: ‘version_t’ has no member named ‘cpu_nbr’
> main.c:230: error: ‘version_t’ has no member named ‘cpu_nbr’
> main.c:235: error: ‘version_t’ has no member named ‘cpu_nbr’
> main.c:245: error: ‘version_t’ has no member named ‘ver_major’
> make: *** [tuxup] Fehler 1
>
> Have I done anything wrong?
>
> Regards,
> Stefan

Got tuxup from svn?

SVN is broken when you fetch old revisions or tags. I changed both tuxup  
and the external commands.h at a certain time, but now when you update to  
an old revision or checkout a tag, you get the current externals and not  
the ones that were available at that time thus the problem you get. So you  
should better download the trunk which compiles just fine normally, or  
update the externals with the same revision number as tuxup (they're on  
the same repository luckily).

Anyone has a suggestion on how to handle this? Should I remove the  
externals when I do a tag and replace with the files directly so they  
won't get changed? Or any other suggestion? Working with the same set of  
files at different places and keeping them in sync manually was difficult  
to maintain, that's how I started with before adding externals.

david

[tuxdroid-user] Problem during installing TuxUp-1.1.0

[Stefan P. <ste...@fh...>]

Hi @ all,

i have tried to follow the how-to
(http://www.tuxisalive.com/documentation/how-to/updating-the-firmware)
to upgrade the firmware of my tux-droid.

I have successfully installed dfu-programmer-0.4.0 but I'm getting an
error when I'm executing the make command from tuxup:

root@redeagle-laptop:/home/redeagle/download/tuxup-0.1.1# make
gcc -lusb -g -Wall -o tuxup main.c bootloader.c usb-connection.c
main.c: In function =E2=80=98check_hex_file=E2=80=99:
main.c:194: error: =E2=80=98version_t=E2=80=99 has no member named =E2=80=
=98cpu_nbr=E2=80=99
main.c:195: error: =E2=80=98version_t=E2=80=99 has no member named =E2=80=
=98ver_major=E2=80=99
main.c: In function =E2=80=98prog_flash=E2=80=99:
main.c:220: error: =E2=80=98version_t=E2=80=99 has no member named =E2=80=
=98cpu_nbr=E2=80=99
main.c:225: error: =E2=80=98version_t=E2=80=99 has no member named =E2=80=
=98cpu_nbr=E2=80=99
main.c:230: error: =E2=80=98version_t=E2=80=99 has no member named =E2=80=
=98cpu_nbr=E2=80=99
main.c:235: error: =E2=80=98version_t=E2=80=99 has no member named =E2=80=
=98cpu_nbr=E2=80=99
main.c:245: error: =E2=80=98version_t=E2=80=99 has no member named =E2=80=
=98ver_major=E2=80=99
make: *** [tuxup] Fehler 1

Have I done anything wrong?

Regards,
Stefan

[tuxdroid-user] Wiki: artificial intelligence topic

[Florent T. <ft...@gm...>]

Hi

I worked a little this w/e, see

http://www2.tux-is-alive.com/wiki/AI

There are python chatbots available, capable of basic command execution.
I see: Speech synthesis + Speech recognition + chatbot = a real nice
command-and-control dialog manager

I also updated http://www2.tux-is-alive.com/wiki/Text-to-speech#Cicero.2BMBROLA
Blind users seem to prefer Cicero+MBROLA. And... it's python.

See you

Florent

[tuxdroid-user] How to detect button presses?

[Florent T. <ft...@gm...>]

hi

i'll soon start modifying the waker, but i need to know how to
integrate the detection of button presses (head, wings).

Some sample code is welcome.

Thanks

Florent

Re: [tuxdroid-user] alarm_clock modifications

[David B. <da...@ja...>]

On Wed, 28 Mar 2007 19:56:51 +0200, Florent THIERY <ft...@gm...>  
wrote:

> Hi
>
> I played a little with the alarm_clock software: i changed it a little
> bit so that the wav file selection becomes a .sh file selection,
> executed using
>
> tux.sys.shell_free("sh %s "%(self.sh_filename))
>
> My sample script contains:
>
> mpg321 -o esd http://85.21.79.5:8040/
>
> ... which is a webradio
>
> It seems to me the launched apps (using shell_free) are not considered
> as child processes... How can i stop/locate the launched processes?

Normally it should be, but why do you use 'sh' before your command?  
Doesn't work here when I do that.
Here's a simple test I did:

david@david-laptop:~/tmp$ cat test.py
#!/usr/bin/python
import sys
sys.path.append('/opt/tuxdroid/api/python')
 from tux import *

tux.sys.shell_free("ps -ef | grep test")

tux.sys.wait(1)
tux.disconnect_from_daemon()

david@david-laptop:~/tmp$ ./test.py
---------------------------------------------------------------
TUXDROID PYTHON API 0.1.2
---------------------------------------------------------------
david     2777 15600  7 14:59 pts/0    00:00:00 /usr/bin/python ./test.py
david     2787  2777  0 14:59 pts/0    00:00:00 sh -c ps -ef | grep test
david     2789  2787  0 14:59 pts/0    00:00:00 grep test


>
> I see that the tux.sys.* are:
> add_time_event
> clear_time_events
> events_list
> parent
> shell
> shell_free
> time
> time_events_Thread
> wait
>
> Can you explain a little how/what these functions do? How to act on
> running events, etc...

I personally can't as I don't know much more than you, still didn't do  
much with the api yet. But as we urged rémi to write the documentation, he  
should be adding docstrings in the api pretty soon.

I also suggested we write a tutorial with a script that would be well  
documented and would demonstrate some functions/functionalities of the api  
one by one in a sequence. That would help a lot to understand how to use  
the api. This tutorial, once published on tuxisalive, will be copied in  
the wiki to extend it to every function that is available in the api. When  
really complete and mature, it will replace the simple one on the website.

So at the moment, I can't be of much help except urging to get that  
documentation.

cheers,
david