Re: [tuxdroid-user] Hello; Working with svn ; several questions & suggestions
Status: Beta
Brought to you by:
ks156
From: David B. <da...@ja...> - 2007-03-13 16:16:24
|
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 |