tux-droid-user

[tuxdroid-user] Hello; Working with svn ; several questions & suggestions

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

Hi everybody. I'm a proud owner of a tuxdroid (recieved today); after
an update, everything works fine :) A little bit surprised by the
sound made by motors, but happy enough.

I synced the svn in order to get the latest version, but i have a
problem: when you want to use svn versions of user programs, the call
to the api is static ( /opt/tuxdroid/api/python ) whereas the actual
svn version is in the trunk subdir ( /opt/tuxdroid/api/python/trunk );
i modified the path in the sample programs (gtui, alarm clock...)

- what will happen upon update? what's the "correct" way to do it?
Copy it at the root dir?
- what about a python egg (easy_install) ?
- about the sound capabilities, is the capacity permanently limited? I
guess real time transcoding do the job? (i tried listening some music
with xmms, heared nothing but crap...), but if i was to plug tux on
"real" speakers, would the quality still be very limited?
- about the waker, does the computer need to be ON ? Or is tux autonomous?
- about waking the host computer up: do you think it would be feasible
to add usb keyboard emulation to the usb dongle? If we managed to
simulate a keypress, we could wake the computer up (but i guess the
dongle needs power; then why should an usb keyboard do the job?)
- what are the line out quality capabilities?
- would it be possible to detect motors forcing? I'm thinking of the
rotation motors: if we (slightly) force tux to turn, can we detect it?
That would add 2 more "switches", ideal for volume adjustment

Sorry for this bunch of random questions :)

I'm willing to help developing the waker functionnality (i really need
a good waker), thinking of webradios, rss headlines reading, X10 &
randomization of "unlocking" sequence.

I'll also consider using a NSLU2 or comparable for always-on operation
(i'm very reluctant in regard of letting my main desktop on all the
time...).

Anyway, this device looks like a fun toy for grown ups :) I'll try to
bring my stone.

Florent

Re: [tuxdroid-user] Hello; Working with svn ; several questions & suggestions

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

On Tue, 13 Mar 2007 03:07:06 +0100, Florent THIERY <ft...@gm...>  
wrote:

> Hi everybody. I'm a proud owner of a tuxdroid (recieved today); after
> an update, everything works fine :) A little bit surprised by the
> sound made by motors, but happy enough.

Hi Florent,
Mechanics and motors are what they use in standard toy factories. We  
worked on reducing the noise and the result is satisfactory I think. It's  
not 'silent' but quite good for a toy. Using more high tech components  
would have improved that indeed but at a much higher cost so we had to  
make a choice.

> I synced the svn in order to get the latest version, but i have a
> problem: when you want to use svn versions of user programs, the call
> to the api is static ( /opt/tuxdroid/api/python ) whereas the actual
> svn version is in the trunk subdir ( /opt/tuxdroid/api/python/trunk );
> i modified the path in the sample programs (gtui, alarm clock...)

I hope someone good enough will be able to clean up that folder hierarchy  
and come up with a proposal for a new structure. The python api should  
probably be packaged with distutils so should move from there.

> - what will happen upon update? what's the "correct" way to do it?
> Copy it at the root dir?

For now, I would do a checkout of the api trunk only:
svn co https://svn.kysoh.com/api/python/trunk /opt/tuxdroid/api/python

> - what about a python egg (easy_install) ?

Unfortunaltely I missed the presentation of Olivier Grizel on packaging  
python products so I've no idea but Olivier is on this list, maybe he can  
give us some hints on what to do here, Olivier?

> - about the sound capabilities, is the capacity permanently limited? I
> guess real time transcoding do the job? (i tried listening some music
> with xmms, heared nothing but crap...), but if i was to plug tux on
> "real" speakers, would the quality still be very limited?

The sound format we can send through the RF is 8 bits 8kHz, no matter what  
speaker you use. That's not a lot but should still give you much better  
results than 'crap' ;-) Do you use the firmware update for the dongle? The  
sound quality has significantly improved there. Using speakers will  
improve the low-end response (bass) as the small internal speaker has a  
limited bandwidth there.

> - about the waker, does the computer need to be ON ? Or is tux  
> autonomous?

The computer needs to be ON. Though it may be possible to hack the  
firmware to add a poor-man RTC maybe (real time clock) which, with some  
calibration, could keep trig some functions at certain time events. But I  
have no idea of the precision we could get and I wouldn't rely on that for  
an alarm clock. So yes, you need the computer.

> - about waking the host computer up: do you think it would be feasible
> to add usb keyboard emulation to the usb dongle? If we managed to
> simulate a keypress, we could wake the computer up (but i guess the
> dongle needs power; then why should an usb keyboard do the job?)

Interesting question. As we can reprogram the dongle and if that's  
possible, that may be a good idea to implement.

> - what are the line out quality capabilities?

Line out is 8 bits 8kHz mono

> - would it be possible to detect motors forcing? I'm thinking of the
> rotation motors: if we (slightly) force tux to turn, can we detect it?
> That would add 2 more "switches", ideal for volume adjustment

The clutch will trigger if you force the gearbox so it won't work probably.

>
> Sorry for this bunch of random questions :)
>
> I'm willing to help developing the waker functionnality (i really need
> a good waker), thinking of webradios, rss headlines reading, X10 &
> randomization of "unlocking" sequence.
>
> I'll also consider using a NSLU2 or comparable for always-on operation
> (i'm very reluctant in regard of letting my main desktop on all the
> time...).

Yep, that's the way to go I think, I bought one but it's still in the box  
since 1 month now, don't have enough time to do all what I want to ...

>
> Anyway, this device looks like a fun toy for grown ups :) I'll try to
> bring my stone.
>
> Florent

We certainly need developments before getting something really usefull.  
Thanks to join the group.
david

Re: [tuxdroid-user] Hello; Working with svn ; several questions & suggestions

[Olivier G. <oli...@en...>]

David Bourgeois a écrit :

>> - what about a python egg (easy_install) ?
> 
> Unfortunaltely I missed the presentation of Olivier Grizel on packaging
> python products so I've no idea but Olivier is on this list, maybe he
> can give us some hints on what to do here, Olivier?

Hi David, hi all,

My FOSDEM slides are now online:

  http://linuxfr.org/2007/03/04/22154.html#809756

Direct link for the egg packaging tutorial:

  http://champiland.homelinux.net/fosdem2007/eggs_howto/eggs_howto.html
  http://champiland.homelinux.net/fosdem2007/eggs_howto/eggs_howto.txt

However this tutorial does not show how to package binary extensions. Please
refer to the official documentation for both distutils and setuptools:

  http://docs.python.org/dist/

and:

  http://peak.telecommunity.com/DevCenter/setuptools

You can also take a look at how other projects build eggs with binary extensions
such as the lxml project for instance.

I'm sorry I have not enough spare time to hack the droid right now but I can try
and help guide a volonteer for such a task.

-- 
Olivier

Re: [tuxdroid-user] Hello; Working with svn ; several questions & suggestions

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

On Tue, 13 Mar 2007 14:03:46 +0100, Olivier Grisel  
<oli...@en...> wrote:

> I'm sorry I have not enough spare time to hack the droid right now but I  
> can try
> and help guide a volonteer for such a task.
>

Thanks! That's much appreciated, it's invaluable to get some thoughts of  
someone that know how to get things right.

I would like to have a look into that and fix the final structure of the  
folder tree of our software before releasing a binary package that will  
install everything.

Re: [tuxdroid-user] Hello; Working with svn ; several questions & suggestions

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

> Thanks! That's much appreciated, it's invaluable to get some thoughts of
> someone that know how to get things right.

I just wanted to say, as a user, that easy_install ROCKS :) When well
done, it's flawless and transparent. As almost everything here will be
python, it may be a good choice.

Some other questions:
- what about autonomy ? Standby (idle) time? "Regular use" battery
time? I know there won't be an answear, but i'd like to get a rough
estimation
- is there a mean of knowing the battery level (voltage) ?
- about IR: what can we do with it? I mean, of course using the
remote, but can tux emit IR? Or is it just recieving? Because if yes,
it means tux could act as the first vocal universal remote :)
- about voice recognition: any plans yet? TTS is nice, but voice
recognition would be awesome, primarily for bash/python script
launching (X10 controlling, login, ...)
- about mic : quality? Enough for basic voice recognition? What's the
peripheral (/dev/?) ?
- about service unification: is there a planned "super software", in
charge of launching and managing the queuing of all the software (with
app downloading for instance)?
- python question: what's the "command"/call for knowing the existing
objects? sort of "ls tux.cmd.* " ; i forgot it... I'm kinda python
newbie
- little feedback: at first my tux wasn't working at all ("dongle busy
or disconnected"), had to upgrade firmware, but then, everythin's ok.
The howto is cool, but lacks a little bit of clarity for the final
step (tux upgrading, apart RF). The tuxup -a worked, but looks a bit
dangerous...

And, an off one: does kysoh plan other toys in the future? I guess it
depends on the success of this very one...

Florent

Re: [tuxdroid-user] Hello; Working with svn ; several questions & suggestions

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

On Tue, 13 Mar 2007 15:41:24 +0100, Florent THIERY <ft...@gm...>  
wrote:

> Some other questions:
> - what about autonomy ? Standby (idle) time? "Regular use" battery
> time? I know there won't be an answear, but i'd like to get a rough
> estimation

Didn't do checks yet but that should be a around 15h but that depends on  
mutliple factors.
We need to implement the sleep mode and I hope to reach much longer  
battery life then, a few days probably.

> - is there a mean of knowing the battery level (voltage) ?

Yep, voltage should be there but not implemented yet, that should not be  
very hard though. But I have no idea on how to get a battery level out of  
that.

> - about IR: what can we do with it? I mean, of course using the
> remote, but can tux emit IR? Or is it just recieving? Because if yes,
> it means tux could act as the first vocal universal remote :)

Atm only RC5 works, you can receive all RC5 codes and send them. I found  
an application note to be able to have a universal receiver/emitter but I  
would want to know if this will be compatible with lirc before doing so.

> - about voice recognition: any plans yet? TTS is nice, but voice
> recognition would be awesome, primarily for bash/python script
> launching (X10 controlling, login, ...)

No plans from me, I would like to try it but there are much more things to  
do so I'll probably wait for someone to try it first :-)

> - about mic : quality? Enough for basic voice recognition? What's the
> peripheral (/dev/?) ?

Here it's in /dev/dsp1 but that depends on your settings and what other  
cards you have. Alsa should display it too. The quality is fine, but it's  
also 8 bits 8kHz. That should be fine for voice recognition.

> - about service unification: is there a planned "super software", in
> charge of launching and managing the queuing of all the software (with
> app downloading for instance)?

Yes we thought about that, to have a master application and plugins you  
could install/remove and monitor. Rémi is working into that direction but  
I would prefer to have small scripts that work and a good daemon before  
doing that. Or that someone which has a good understanding of tux and such  
a structure.

> - python question: what's the "command"/call for knowing the existing
> objects? sort of "ls tux.cmd.* " ; i forgot it... I'm kinda python
> newbie

I'm not better than you. But you can use dir(tux) or dir(tux.cmd)
We should use doxygen to generate all the documentation. Someone already  
created the missing configuration file though for the moment you'll get a  
listing of all the functions with only few documentation. You can also  
look at the python class directly and start documenting it ;-)

> - little feedback: at first my tux wasn't working at all ("dongle busy
> or disconnected"), had to upgrade firmware, but then, everythin's ok.
> The howto is cool, but lacks a little bit of clarity for the final
> step (tux upgrading, apart RF). The tuxup -a worked, but looks a bit
> dangerous...

OK, will have a look at it. tuxup -a is not dangerous as long as you use  
the hex files we provide (svn or futur releases). we never got any  
problem. I added that warning in case people start to mess up with  
firmwares or edit the hex files manually.

>
> And, an off one: does kysoh plan other toys in the future? I guess it
> depends on the success of this very one...

I don't know exactly about their plans but they should have. And indeed  
the success of this one will probably influence what will happen.

david

Re: [tuxdroid-user] Hello; Working with svn ; several questions & suggestions

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

> > - what about autonomy ? Standby (idle) time? "Regular use" battery
> > time?
> Didn't do checks yet but that should be a around 15h but that depends on
> mutliple factors. We need to implement the sleep mode and I hope to reach much longer
> battery life then, a few days probably.

I guess my tux will stay plugged in then :)

> Yep, voltage should be there but not implemented yet, that should not be
> very hard though. But I have no idea on how to get a battery level out of
> that.

As long as we can retrieve a voltage value, we have to use/create a
model of the battery's voltage evolution. I guess acpi's guessing (the
one you get when typing "acpi") relies on such a model, and would give
us hints. What type of battery is it?

> > - about IR: what can we do with it? I mean, of course using the
> > remote, but can tux emit IR? Or is it just recieving? Because if yes,
> > it means tux could act as the first vocal universal remote :)
>
> Atm only RC5 works, you can receive all RC5 codes and send them. I found
> an application note to be able to have a universal receiver/emitter but I
> would want to know if this will be compatible with lirc before doing so.

There's a feature that would be great if tux can emit: a IR recording
mode; you just type the sequences on your regular remote in front of
tux, then you assign a vocal command to them (ex: tv on + dvd player
on + switch tv source + open tray...). We don't really need our
software to "understand"/know the devices, do we? Just mimicking...

> > - about mic : quality? Enough for basic voice recognition? What's the
> > peripheral (/dev/?) ?
> That should be fine for voice recognition.

I'd love to log in/out using voice, or simply audiosudo ^_^ (a pam module?)

> I would prefer to have small scripts that work and a good daemon before
> doing that [super app].

Sure, that's logical :)

> > - python question: what's the "command"/call for knowing the existing
> > objects?
>
> I'm not better than you. But you can use dir(tux) or dir(tux.cmd)

Thx, that's what i was looking for.

> We should use doxygen to generate all the documentation. Someone already
> created the missing configuration file though for the moment you'll get a
> listing of all the functions with only few documentation. You can also
> look at the python class directly and start documenting it ;-)

I started to look, but i lack practical skill and tux knowledge. Plus,
i'm out of time for now, but i may have some in a while.

Thanks for the answears !

Florent

Re: [tuxdroid-user] Hello; Working with svn ; several questions & suggestions

[Olivier G. <oli...@en...>]

Florent THIERY a écrit :

>>> - python question: what's the "command"/call for knowing the existing
>>> objects?
>> I'm not better than you. But you can use dir(tux) or dir(tux.cmd)

There is also help(tux) to display the inline documentation of the object
(provided someone wrote meaningful docstrings ;)

You should have a look at the ipython interactive shell that has <tab> based
autocompletion.

There are some screencasts here:
http://showmedo.com/videos/series?name=PythonIPythonSeries

-- 
Olivier

Re: [tuxdroid-user] Hello; Working with svn ; several questions & suggestions

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

On Tue, 13 Mar 2007 17:39:10 +0100, Florent THIERY <ft...@gm...>  
wrote:

> As long as we can retrieve a voltage value, we have to use/create a
> model of the battery's voltage evolution. I guess acpi's guessing (the
> one you get when typing "acpi") relies on such a model, and would give
> us hints. What type of battery is it?
>
Battery packs have an IC included which monitors the charge/discharge all  
the time. It can get how muh current get's in and out and computes the  
battery level from that. From the voltage, that may work but will be  
inaccurate. First I'll monitor the curves and from that we'll see what we  
can do.

> There's a feature that would be great if tux can emit: a IR recording
> mode; you just type the sequences on your regular remote in front of
> tux, then you assign a vocal command to them (ex: tv on + dvd player
> on + switch tv source + open tray...). We don't really need our
> software to "understand"/know the devices, do we? Just mimicking...

Yes, that's the idea of the universal receiver. Get the raw signal and the  
computer will keep it as raw or decrypt it according to various protocols.

david