Le Tux Droid

Aller au contenu | Aller au menu | Aller à la recherche

lundi, novembre 2 2009

Bientôt le retour

Suite à la dépêche sur DLFP je me suis aperçu que mon dernier billet date de longtemps :-( .

Je n'ai pas abandonné mon Tux Droid, je suivais le développement de son software la V3 et de son environnement graphique Tuxbox V2.

J'en ai profité pour écrire 3 gadgets, un pour la batterie, un pour le chargeur et le dernier en liaison avec le client de messagerie instantané Pidgin en version Linux.

Dés la semaine prochaine je vous expliquerai tout ça plus en détail.

A très bientôt pour la suite.

PS: comment vous pouvez le lire sur la dépêche de DLFP, il y a une promo sur le Tux Droid 99€ au lieu 149€.

vendredi, décembre 12 2008

Le TuxShell - Généralités


Si vous connaissez le langage Python ou si vous avez lu le livre que je vous conseillais dans l'article sur le python, vous savez que le langage est livré avec un shell, pour l'utiliser en mode interactif.

Le software du Tux comprend un programme, qui charge l'API du Tux après avoir lancé le shell python, son nom est tuxsh.

Sous linux, ouvrez un terminal et tapez tuxsh

Sous windows menu Démarrer --> TuxDroid --> Tuxshell

lescau@Pastouche:~$ tuxsh
====================
tuxisalive.api-0.0.3
====================
>>> TuxAPI is connected.


Sous linux ouvrons un terminal et regardons ce programme d'un peut plus près

Ou est ce fichier ?

lescau@Pastouche:~$ whereis tuxsh
tuxsh: /usr/bin/tuxsh


Quel est le type de ce fichier ?

lescau@Pastouche:~$ file /usr/bin/tuxsh
/usr/bin/tuxsh: Bourne-Again shell script text executable


C'est un script, affichons le :

lescau@Pastouche:~$ less /usr/bin/tuxsh


#!/bin/bash
python -i /usr/share/tuxdroid/resources/misc/sh.py


python -i ; lancement de python en mode interactif

regardons le script sh.py

# -*- coding: latin1 -*-

"""
Tux shell
=========
Tux shell is the shell way to use Tuxdroid. It create an API object with the
"Free" client mode.
"""

from tuxisalive.api.version import author, date, version, licence
__author__ = author
__date__ = date
__version__ = version
__licence__ = licence
del author, date, version, licence

#    Copyright (C) 2008 C2ME Sa
#    R<E9>mi Jocaille <remi.jocaille@c2me.be>
#    Distributed under the terms of the GNU General Public License
#    http://www.gnu.org/copyleft/gpl.html

import sys
import signal
import atexit
import os

from tuxisalive.api.TuxAPIConst import *
from tuxisalive.api.TuxAPI import TuxAPI

global tux

tux = TuxAPI("127.0.0.1", 270)

verString = tux.getVersion()
verH = "".join("=" * len(verString))
print verH
print verString
print verH

if os.name != 'nt':
    if not 'readline' in sys.modules:
        print "For interctive use, run: python -i sh.py"
        sys.exit(0)

tux.server.autoConnect(CLIENT_LEVEL_FREE, "TuxShell", "NoPasswd")
tux.tts.isConsole()
def sigExit(signum, frame):
    sys.exit(signum)
   
def exit():
    tux.destroy()
    sys.exit(0)

def myExitFunct():
    tux.destroy()

signal.signal(signal.SIGTERM, sigExit)
signal.signal(signal.SIGINT, sigExit)
atexit.register(myExitFunct)


Les commandes qui concernent le Tux

from tuxisalive.api.TuxAPIConst import *

importation des constantes.

from tuxisalive.api.TuxAPI import TuxAPI

importation de l'objet TuxAPI

tux = TuxAPI("127.0.0.1", 270)

création d'une instance de l'objet TuxAPI que le nomme tux en même temps on passe comme paramètre l'adresse IP ainsi que le port du serveur HTTP (voir le tuxware)

tux.server.autoConnect(CLIENT_LEVEL_FREE, "TuxShell", "NoPasswd")

connection au serveur HTTP avec comme paramètre, le niveau du client (ici FREE), le nom de l'application (TuxShell) et le mot de passe.

tux.tts.isConsole()

fixe l'encodage du synthétiseur de paroles, comme l'encodage de la console.


vendredi, novembre 21 2008

Le serveur HTTP

Dans le billet précédant je vous avais déjà parlé du serveur HTTP, c'est la pièce maîtresse du Tuxware, c'est un serveur d'architecture de type REST

Pour l'expérimenter entrez comme URL http://127.0.0.1:270/

http : c'est le protocole

127.0.0.1 : adresse IP de la machine sur laquelle est installé le TuxDroid, 127.0.0.1 c'est pour une utilisation sur la machine locale, mais vous pouvez le piloter à distance en tapant l'adresse IP de la machine.

270 : c'est le numéro du port auquel répond le serveur.

Le navigateur nous renvoie une page d'aide.

Qu'est ce qui c'est passé ?


L'URL à envoyé une requête "NULL" au serveur et le serveur nous à répondu avec un fichier XML sur ses possibilités, c'est le TuxDroid qui nous répond, le serveur est juste la pour nous aider à envoyer des requêtes.

Regardons de plus près le fichier XML retourné :

  • Des ressources.
  • Pour chaque ressource, ses fonctions utilisables.
  • Pour chaque fonction, le niveau requis et ses paramètres si nécessaire.

Par exemple:

Ressource Mouth (Bouche), fonction Open (Ouvre), niveau requis FREE_CLIENT, paramètre aucun

Les ressources disponibles :


  • Access - Accéder à une ressource
  • Attitune - Gestion de la lecture des fichiers attitunes, fonction charger, jouer ...
  • Sound flash - Gestion de la banque de sons internes
  • Spinning - Gestion de la rotation du TuxDroid, fonction tourner vers la droite, tourner vers la gauche ...
  • Status - Gestion des statuts
  • TTS - Gestion du synthétiseur vocal, fonction fixe le locuteur, le pitch, lecture d'un texte ...
  • Tuxup - Gestion du firmware
  • Wav - Gestion de la lecture des fichiers de type wav
  • js - JavaScript ?
  • Client - Gestion des clients du serveur
  • xsl - service xsl
  • Documentation  - log, services
  • Eyes - Gestion des yeux, fonction ouverture, fermeture ...
  • Flippers - Gestion des ailes, fonction lever, baisser ...
  • IR - Gestion de l'émetteur infra-rouge
  • IdleBehavior - Gestion du service IdleBehavior (comportement du TuxDroid quand il est dans état d'attente)
  • Leds - Gestion des leds des yeux, fonction clignotement, allumer, éteindre ...
  • Macro - ?
  • Mouth - Gestion de la bouche, fonction ouvre, ferme ...

En programmation nous utiliserons le même principe "Ressource.Fonction(paramètre)"


Comment écrire une requête ?



URL type :

http://adresse IP de la machine:port/niveau du client/ressource/fonction?paramètre

les paramètres doivent s'écrire sous forme "chaîne de requête" 

      exemple "text=Bonjour le monde" s'écrira "text=Bonjour%20le%20monde"


le niveau du client :
  • CLIENT_LEVEL_ANONYME = -1
  • CLIENT_LEVEL_FREE = 0
  • CLIENT_LEVEL_RESTRICTED = 1
  • CLIENT_LEVEL_ROOT = 2


exemple pour faire dire à Tux, installé sur ma machine locale, "Bonjour le monde"  on utilisera :

Adresse IP et port du serveur : 127.0.0.1:270
N° du client : 0
Ressource : TTS
Fonction : speak
paramètre : text=Bonjour%20le%20monde

URL = http://127.0.0.1:270/0/tts/speak?text=Bonjour%20le%20monde

Bonjour le monde, avec une voix anglaise, ce n'est pas génial

regardons la liste des locuteurs

http://127.0.0.1:270/0/tts/voices?

résultat : Bruno; Julie, Ryan, Heather (si vous avez comme moi les langues française et anglaise de chargées)

comme on veut parler français prenons un locuteur français (Bruno ou Julie)

Je vais prendre julie http://127.0.0.1:270/0/tts/locutor?name=Julie

maintenant si je relance http://127.0.0.1:270/0/tts/speak?text=Bonjour%20le%20monde

c'est Julie qui parle :-)


Type des paramètres :

<int8> entier sur 8 bits 0 à 256
<float> nombre flottant (avec virgule qui sera un point ici)
<string> chaîne de caractère
<True|False> Vrai | Faux

Attention au type Float un nombre entier s'écrit toujours avec une virgule exemple 2 s'écrit 2.0


Javasript


Pour voir l'utilisation du langage Javascript avec le serveur HTTP

http://127.0.0.1:270/mouth/


Liens :

Page du wiki

lundi, novembre 10 2008

Le Tuxware

Du coté PC le TuxDroid est vu comme un périphérique USB, mais interagir avec le TUX directement à partir des pilotes USB ne serait pas très pratique.

Le Tuxware est une suite d'interfaces de haut niveau qui interviennent sur les pilotes USB à travers des requêtes HTTP.

Les librairies des pilotes

La librairie de contrôle envoie les ordres au Tux et reçoit ses états.

La librairie du son en sortie (OSL) transforme la synthèse vocale en fichier audio type wave, mixe les fichiers, le flux audio résultant est envoyé à l'USB audio.

La librairie du son en entrée (ISL) acquière ou relâche le flux audio d'entrée, s'occupe aussi de la reconnaissance vocale afin d'envoyer les paramètres aux applications. 

Le gestionnaire de ressources.

Tux Droid est un ensemble de ressources. Allouer ces ressources aux différentes applications est le rôle du gestionnaire de ressource.

Le serveur HTTP. 

C'est un serveur dont l'architecture est de type REST, il permet de contrôler le Tux Droid à travers une URL contenant les données à transmettre à l'application.

Comme tout service sous tcp/ip on y accède par l'adresse ip du serveur qui l'héberge et son numéro du port.

par défaut, adresse :127.0.0.1 (machine locale), port : 270.

Si votre Tux est installé en local expérimenté ça : http://127.0.0.1:270

maintenant vous avez une idée de tout ce que vous pouvez envoyer ou recevoir d'informations à votre Tux Droid.

Je parlerai plus longuement du serveur HTTP dans un autre billet.

Les APIs.


C'est un ensemble de fonctions pouvant envoyer des requêtes sous formes d'URL au serveur HTTP.


Pour le moment il existe une API pour les langages Java, Javascript et Python, mais si vous savez écrire des fonctions, dans le langage que vous voulez utiliser, répondant au critère vu ci dessus, vous pouvez créer l'API pour votre langage, n'oubliez pas de la mettre à disposition des autres utilisateurs, c'est ça l'Open Source  ;-)

 


Pour plus d'information voir la page du Wiki sur le Tuxware

jeudi, novembre 6 2008

Le hardware du Tux Droid

Le mieux c'est de lire les pages sur le wiki.

Pour Fux le dongle USB : http://wiki.tuxisalive.com/index.php/Dongle_Electronics

Pour le Tux Droid : http://wiki.tuxisalive.com/index.php/Inside_Tux_Droid

Avec le schéma sur le wiki on comprend l'essentiel



- page 1 de 3