Thread: [tuxdroid-user] How tuxes "see" each other?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi,

I saw those standalone features allowing 2 tuxes to greet each other.
But actually how do they "see" each other?
RF ping?
IR ping?

Phil

Yep, it's IR but it doesn't work correctly. We didn't have enough time t=
o  =

fix that before production and since priorities have changed.

I think this feature should be handled by the standalone behavior and th=
e  =

event manager in the firmware instead of the ir functions directly. As I=
'm  =

planning to rewrite the ir functions at some point, I didn't try to fix =
 =

the greeting event.

Normally, you should have 1 tux that sends a code, the other one sees it=
,  =

says greet1 and send another code, the first tux receives that code, say=
s  =

greet2 and sends a thirs code that the second tux detects again and says=
  =

greet3. But usually you'll get greet1 and occasionally greet2 but that's=
  =

all.

david which is back in localtime ;-)

On Mon, 19 Mar 2007 18:17:51 +0100, Philippe Teuwen <ph...@te...>  =

wrote:

> Hi,
>
> I saw those standalone features allowing 2 tuxes to greet each other.
> But actually how do they "see" each other?
> RF ping?
> IR ping?
>
> Phil
>
>
>
> ----------------------------------------------------------------------=
---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to shar=
e  =

> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=
=3DDEVDEV
> _______________________________________________
> tux-droid-user mailing list
> tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tux-droid-user

About standalone features: could you please try describing how far
these feature could go?

On Mon, 19 Mar 2007 21:02:54 +0100, Florent THIERY <ft...@gm...>  
wrote:

> About standalone features: could you please try describing how far
> these feature could go?

Sorry but that'll take some time to write something clear and I'll add a  
page about this on the wiki but I have other priorities now. I'll tell you  
when it's ready, it'll be there: http://www2.tux-is-alive.com

But in a few words, right now we can only store some small sequences of  
tux commands (sounds, movements, leds, send IR,...). Then you can trigger  
one of these sequences from an event. These events needs to be hardcoded  
in the firmware but we can have them even if we don't use them.

What I planned to do at first is to have:
- configuration registers in flash and eeprom that enable/disable events
- events associated to sequences
- sequence definitions in eeprom

When you press on the head button, I should do:
- detect the head button
- if the configuration register for the head button event is enabled, I  
emmit the head button event
- the head button event will launch the head button sequence which is  
stored in eeprom ans is a blink of the blue led's

I would like to be able to configure that from the computer by:
- enabling or disabling events (registers changed in flash so when you  
switch off, you loose your changes)
- storing configuration registers in eeprom to keep changes permanently
- customizing the sequences in eeprom

Maybe we can also have 2 sets of configuration registers so one is valid  
when tux is connected to the RF and one when tux is really in standalone.

You could do much more with standalone but then you'll have to customize  
the firmware directly and because the memory is limited, you're likely to  
have to remove stuff to add what you want to do. But it should be possible  
to add stuff on the I2C bus like temperature/humidity sensors,  
accelerometers,... you may also have to open tux and alter the circuit if  
you want to connect other things. If you don't do that, you're limited  
anyway by the input of tux which is only a few buttons, light and IR.

HTH,
david

Sorry to talk again about that, but would it be possible for tux to
trigger an action from the hub? The fish is unpowered when the
computer is shut down, right?

What i don't get is: a keyboard press can power a computer up (acpi
bios function) when it's off. Could we do the same with the fish?

For that we would need:
- a built in timer for standalone waker functionnality (in tux) -> how feasible?
- usb keyboard press emulation on the fish

But the more i think about it, the less it seems doable...

On Wed, 21 Mar 2007 13:05:18 +0100, Florent THIERY <ft...@gm...>  
wrote:

> Sorry to talk again about that, but would it be possible for tux to
> trigger an action from the hub? The fish is unpowered when the
> computer is shut down, right?
>
> What i don't get is: a keyboard press can power a computer up (acpi
> bios function) when it's off. Could we do the same with the fish?
>
> For that we would need:
> - a built in timer for standalone waker functionnality (in tux) -> how  
> feasible?
> - usb keyboard press emulation on the fish
>
> But the more i think about it, the less it seems doable...

A timer is no real problem though you'll never get it accurate. Need to do  
some tests about calibration but we would have need a crystal and a real  
time clock to do such a thing.

The main issue comes from the powering, if the dongle is unpowered,  
there's no way to get connected with Tux. Can a usb keyboard wake-up your  
computer? I don't think so.

Now if we can startup the computer from a logic signal connected  
somewhere, a hack that could power the dongle separately and adding an  
output from the RF board of the dongle and a custom firmware could do the  
trick. That's something we can imagine. But to wake-up your computer at a  
certain time, you better use your bios or build a small real time clock  
that connects to the computer directly. Or use an old wakeup clock with  
the hammers and bells and stick it close to your keyboard  so the hammers  
hit it :-)

> A timer is no real problem though you'll never get it accurate. Need to do
> some tests about calibration but we would have need a crystal and a real
> time clock to do such a thing.

At least we would have a "real" waker functionnality; plus, the sound
of motors can easily frighten you up in the morning :)

> The main issue comes from the powering, if the dongle is unpowered,
> there's no way to get connected with Tux. Can a usb keyboard wake-up your
> computer? I don't think so.

I found this (concerns A7N8X mb):

"The USB device wake-up feature requires a power supply that can
provide 500 mA ... for each USB port. Otherwise, the system would not
power up."

So, if we use a powered usb hub...

> Or use an old wakeup clock with
> the hammers and bells and stick it close to your keyboard  so the hammers
> hit it :-)

LOL. Or simply make the hammer hit me instead.

I think i'll buy an NSLU2 for always-on operation. That way, the NSLU2
will be able to send wake on lan packets to the desktop (on
hibernation only).

Still, it sets new problems: no gui ! How can i use tux apps if tux is
connected on NSLU2 on my main desktop?
- Simply let the daemon run on the NSLU2, and connect to this daemon
from my desktop ? But then the python apps will be closed when the
computer sleeps. I will be limited to non-gui only apps :(
- Or nfs/samba share the devices? I'm getting confused now :-p

Yep, a powered usb hub may help probably, though a special firmware needs  
to be done but that seems possible.

> I think i'll buy an NSLU2 for always-on operation. That way, the NSLU2
> will be able to send wake on lan packets to the desktop (on
> hibernation only).
>
> Still, it sets new problems: no gui ! How can i use tux apps if tux is
> connected on NSLU2 on my main desktop?
> - Simply let the daemon run on the NSLU2, and connect to this daemon
> from my desktop ? But then the python apps will be closed when the
> computer sleeps. I will be limited to non-gui only apps :(
> - Or nfs/samba share the devices? I'm getting confused now :-p

NSLU2 is certainly the solution to go for ow as it seems easier and will  
give you much more functionality. The daemon can run on the slug and you  
can still use your gui's or scripts from any computer as they communicate  
together through tcp/ip.
Then we can also have a client on the slug itself that could handle your  
wakeup clock, get sounds/text from the internet to stream it to your tux.  
That would be a great functionality yo have soon.

I removed the packaging of my slug yesterday, I'm now determined to give  
it a go, I think I'll try to install gentoo on it. We should do it  
together and track this on the wiki. I'll add a page there.

On 3/21/07, David Bourgeois <da...@ja...> wrote:
> Yep, a powered usb hub may help probably, though a special firmware needs
> to be done but that seems possible.
>
> > I think i'll buy an NSLU2 for always-on operation. That way, the NSLU2
> > will be able to send wake on lan packets to the desktop (on
> > hibernation only).
> >
> > Still, it sets new problems: no gui ! How can i use tux apps if tux is
> NSLU2 is certainly the solution to go for ow as it seems easier and will
> give you much more functionality. The daemon can run on the slug and you
> can still use your gui's or scripts from any computer as they communicate
> together through tcp/ip.

Indeed, but if i close the waker's GUI, the waker won't work right?

> Then we can also have a client on the slug itself that could handle your
> wakeup clock, get sounds/text from the internet to stream it to your tux.
> That would be a great functionality yo have soon.

That's what i'm aiming :)

By the way: i think the way to go for tux python apps is interfacing
with regular software: mpd, x10 controlling apps, etc. What's the way
to go? sysexecs?

> I removed the packaging of my slug yesterday, I'm now determined to give
> it a go, I think I'll try to install gentoo on it. We should do it
> together and track this on the wiki. I'll add a page there.

We may try rolling our own angstr=F6m distro

I'm also considering a WL-500gP over the NSLU2 (not significantly more
expensive; maybe even less, and more powerful, + wifi ! + switch).
What could be awesome: starting with dd-wrt, and add custom web
interface controls for tux (ex: a waker tab :p). Installing a single
tux ipkg may add the daemon, python apps + webif extension at once.

>From NSUL2 homepage: "There are also Downloadable Packages available
for the Unslung firmware and also for other devices like the Asus
WL-500g,WL-HDD, WL-500gx, WL-500gP routers, the Synology DS-101 and
DS-101g+ NAS devices, and other wireless routers with support for
external storrage and based on Oleg or DD-WRT firmware."

So, a single package may work for both NSLU2 & DD-WRT.

On Wed, 21 Mar 2007 14:25:06 +0100, Florent THIERY <ft...@gm...>  =

wrote:

> On 3/21/07, David Bourgeois <da...@ja...> wrote:
>> Yep, a powered usb hub may help probably, though a special firmware  =

>> needs
>> to be done but that seems possible.
>>
>> > I think i'll buy an NSLU2 for always-on operation. That way, the NS=
LU2
>> > will be able to send wake on lan packets to the desktop (on
>> > hibernation only).
>> >
>> > Still, it sets new problems: no gui ! How can i use tux apps if tux=
 is
>> NSLU2 is certainly the solution to go for ow as it seems easier and w=
ill
>> give you much more functionality. The daemon can run on the slug and =
you
>> can still use your gui's or scripts from any computer as they  =

>> communicate
>> together through tcp/ip.
>
> Indeed, but if i close the waker's GUI, the waker won't work right?

Yes, but we'll need a kind of aggregator program, somethink that manages=
  =

all functionalities you want your Tux to have. I put some thoughts about=
  =

this on the wiki:  =

http://www2.tux-is-alive.com/wiki/New_software_architecture
Basically, you could have a manager on your computer for all stuff that =
 =

occurs there, but the waker should be on the manager running on the slug=
.  =

We still need an access to that manaer from the computer for configurati=
on  =

but after it should be able to run alone.

> I'm also considering a WL-500gP over the NSLU2 (not significantly more=

> expensive; maybe even less, and more powerful, + wifi ! + switch).
> What could be awesome: starting with dd-wrt, and add custom web
> interface controls for tux (ex: a waker tab :p). Installing a single
> tux ipkg may add the daemon, python apps + webif extension at once.
>
> From NSUL2 homepage: "There are also Downloadable Packages available
> for the Unslung firmware and also for other devices like the Asus
> WL-500g,WL-HDD, WL-500gx, WL-500gP routers, the Synology DS-101 and
> DS-101g+ NAS devices, and other wireless routers with support for
> external storrage and based on Oleg or DD-WRT firmware."
>
> So, a single package may work for both NSLU2 & DD-WRT.

Yep, feel free to share your experiences on the wiki too, the page will =
be  =

http://www2.tux-is-alive.com/mediawiki/index.php?title=3DNAS

> Basically, you could have a manager on your computer for all stuff that
> occurs there, but the waker should be on the manager running on the slug.
> We still need an access to that manaer from the computer for configuration
> but after it should be able to run alone.

So the gui would be used ONLY for application
setup/activation/options? Upon "OK", it stores the parameters and the
execution will be scheduled in the aggregator?

On Wed, 21 Mar 2007 15:58:24 +0100, Florent THIERY <ft...@gm...>  
wrote:

>> Basically, you could have a manager on your computer for all stuff that
>> occurs there, but the waker should be on the manager running on the  
>> slug.
>> We still need an access to that manaer from the computer for  
>> configuration
>> but after it should be able to run alone.
>
> So the gui would be used ONLY for application
> setup/activation/options? Upon "OK", it stores the parameters and the
> execution will be scheduled in the aggregator?

Yes, for the aggregator running on the slug, we need something like this.  
For the aggregator running on the computer, it doesn't really matter.

I thought of having the manager (or aggregator) very light and which  
handles the configuration and priorities/routing. Then a set of plugins  
could be installed, each plugin offering a functionality for tux. On a  
slug, you could have a waker plugin, a wheather plugin and an email plugin  
for example. Configuration could be done through a gui or simply  
configuration files. If you get an email, pressing on the head would read  
the emil, but if tux was waking you up, pressing on the head would stop  
the alarm. And pressing on the head when no event occured would tell the  
wheather forecast. That's the manager that should be able to route these  
events between the daemon and the plugins.

That's maybe not the good way to implement it but basically managing  
different functionalities is the problem we'll have to solve in the  
future. And having a computer running continuously is not something we  
usually accept so being able to run the daemon and the 'manager' on a  
small box is really necessary.