Éditions disponibles
Project license
Licence Publique Générale GNU Version 2
De quoi ça cause ?
TuxDroid API Java is simple (but I hope efficient) Java front end for Kysoh robot.
Description
The robot is originally delivered with a Python API that is quite good. But as I'm not a python coder, I decided to write my own implementation using Java way of doing things (threading, listeners, etc...). For now, it's far from the Python version but I have quite all the basics.
This project use Maven2, so it should be easy to build. There is only one dependency on my own libraries that is included in the binary package. Everything else is in JDK or downloadable with maven.
The API is build for and with JDK 1.6. As it's a "for pleasure" library, I don't think compliance with JDK 1.4 is very useful. And anyway it will be quite complicated to back-port it as I massively use generics. So it should work on JDK 1.5 but never I think older versions.
JDK 1.6 itself is specifically really used but I have in mind a better Desktop integration when the test application will become a fully desktop integrated TuxDroid Gadget container.
About howto to get start with this, I'll soon add a proper JavaDoc, but in the mid time there is a small documentation (have a look to the link on your right side).
The API comes with a very simple Test application using Swing. Main purpose of it is to have a data communication logger and allow me (and you 
to control Tux using the remote control. You can start the test application easily by just untaring the binaries and runing ./bin/tuxDroid.sh. Normally this should also work On Windows, but I didn't try yet (what the point anyway ?
I hope you'll have fun with this as I had (and still have) to write it.
- répondre
sonny , le 3 October, 2007 - 10:13Hey super!
Mais je suis un peu jaloux que tu privilégie la communauté anglophone comme ça!
- répondre
sonny , le 3 October, 2007 - 10:22Hey regarde ça, http://linuxfr.org/~Montaigne/25392.html ça serait super de pouvoir programmer tuxdroid avec ce type de language
- répondre
Ulhume, le 3 October, 2007 - 11:00C'est juste que lorsqu'il s'agit de projets, ça élargit la communauté de faire cela en anglais. C'est une sorte d'esperanto en quelque sorte
Mais j'ai bien dans l'idée de traduire la page de doc à un moment où à un autre, pas de soucis.
Sinon pour le truc de Liu, j'avais vu cela mais je suis définitivement pas un fan de python
C'est sûrement un très bon langage de script mais j'ai tout de même une préférence pour java lorsqu'il s'agit de faire une application. Pour les choses bien complexe, ça produit un code plus propre, et là, pour l'API Tux, lorsque je regarde la gueule de la démo, ça commence à être bien complexe car finalement cela ressemble de plus en plus au manager de gadgets 
- répondre
sonny , le 3 October, 2007 - 12:43Je n'ai malheureusement aucune connaissance en java
. Ce que j'aurais aimé c'est un portage du language urbi sur notre python.
http://fr.wikipedia.org/wiki/URBI
- répondre
Ulhume, le 3 October, 2007 - 12:54T'as des connaissances en quel langage ? Car sérieusement, dans le cadre du boulot, je l'ai enseigné à des vraies quiches, et avec succès
Le gros avantage du Java sur Python, c'est sa syntaxe beaucoup plus poussée où l'objet, le threading, etc.. sont directement intégré aux langage. Je n'ai pas de connaissances poussées en python, mais lorsque je lisais le code de l'API d'origine et que je vois le bordel que c'est de gérer des threads, je remercie la dite syntaxe 
Pour te donner une idée, un mutex en java c'est :
{
// code protégé
}
A comparer avec l'équivalent Python...
Mais bon, ceci est une question de goûts.
- répondre
sonny , le 3 October, 2007 - 13:32Enfait je n'ai pas de connaissance très poussé en python non plus...
Je développe en XUL sur la plateforme XULrunner de mozilla.
- répondre
Ulhume, le 3 October, 2007 - 13:35Intéressant ça ! J'avais une question justement, alors j'en profite
Y t'il un moyen pour créer une application XUL stant-alone. Comme FireFox en quelque sorte ? Si tu as des liens sur ce sujet, je suis preneur.
NB: Une autre étape de l'API Java du tuxdroid, c'est des WebServices
Ca risque de plus t'interessé là, non ? 
- répondre
Comète , le 5 October, 2007 - 14:28Oui avec Xulrunner !
- répondre
Ulhume, le 5 October, 2007 - 14:34Bookmarké, merci
))
- répondre
sonny , le 5 October, 2007 - 15:49http://developer.mozilla.org/fr/docs/XULRunner
)
XULrunner est une plateforme terrible, son gros problème est le manque de documentation et pour certain un IDE complet (moi je me contente de Kate
- répondre
Renaud Bruyeron , le 9 October, 2007 - 09:14Interessant! y'a-t-il un SVN ou un CVS pour cette API ?
- répondre
Ulhume, le 9 October, 2007 - 09:19Non car pour l'instant aucune âme ne s'est déclaré pour bosser avec moi là dessus
Pourquoi cette question ?
- répondre
Renaud Bruyeron , le 9 October, 2007 - 09:54La raison:
$ tar xjf ~/Desktop/tuxDroid-0.3-sources.tar.bz2
$ cd tuxDroid-0.3/
$ mvn compile
[INFO] Scanning for projects...
Downloading: http://repo1.maven.org/maven2/net/karmaLab/integration/1.0/integration-1...
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).
Project ID: net.karmaLab.toolkit:tuxDroid:jar:0.3
Reason: Cannot find parent: net.karmaLab:integration for project: net.karmaLab.toolkit:tuxDroid:jar:0.3 for project net.karmaLab.toolkit:tuxDroid:jar:0.3
Il manque des choses dans le package -sources visiblement. Idem dans le package -binairies où il manque le folder bin/.
- répondre
Renaud Bruyeron , le 9 October, 2007 - 09:57J'ai essayé le package -binaries, mais pas de folder bin/ dedans. J'ai ensuite downloadé le package -sources, mais je n'arrive pas à builder:
$ tar xjf ~/Desktop/tuxDroid-0.3-sources.tar.bz2
$ cd tuxDroid-0.3/
$ mvn compile
[INFO] Scanning for projects...
Downloading: http://repo1.maven.org/maven2/net/karmaLab/integration/1.0/integration-1...
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).
Project ID: net.karmaLab.toolkit:tuxDroid:jar:0.3
Reason: Cannot find parent: net.karmaLab:integration for project: net.karmaLab.toolkit:tuxDroid:jar:0.3 for project net.karmaLab.toolkit:tuxDroid:jar:0.3
- répondre
Renaud Bruyeron , le 9 October, 2007 - 09:59le package -binaries ne contient pas le folder bin/ décrit dans le README, et le package -sources n'est pas compilable sans ses dépendances:
cd tuxDroid-0.3/
mvn compile
[INFO] Scanning for projects...
Downloading: http://repo1.maven.org/maven2/net/karmaLab/integration/1.0/integration-1.0.pom
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).
Project ID: net.karmaLab.toolkit:tuxDroid:jar:0.3
Reason: Cannot find parent: net.karmaLab:integration for project: net.karmaLab.toolkit:tuxDroid:jar:0.3 for project net.karmaLab.toolkit:tuxDroid:jar:0.3
- répondre
Renaud Bruyeron , le 9 October, 2007 - 10:01Bon je n'arrive pas à poster de code dans ce systeme
En bref, le download -binaries ne contient pas le folder bin/ décrit dans le README, et le package -sources ne builde pas sous mvn (il manque les dépendances, donc il faut sans doute déclarer un repository mvn dans le pom.xml ou dans son settings.xml, mais lequel?)
Donc voila la raison
- répondre
Ulhume, le 9 October, 2007 - 10:03Non, il ne manque rien, il faudrait juste que je trouve le temps de faire un POM stand-alone. Les librairies que l'API utilise sont dans le ./lib mais comme je travaille sur tout en même temps, et que les librairies servent à d'autres projet, j'ai un POM parent (janus.integration), qui fait la colle. Logiquement si tu vires la dépendance parent, et que tu intègres les jar (section dependencies) de ./lib dans ton repo local, tu devrais pouvoir compiler sans problèmes.
Tout ce mig-mac tient à une quadrature du cercle que je n'arrive pas à résoudre avec Maven :
1/ J'ai des librairies que je fait évoluer avec mes projets.
2/ J'ai N projets qui utilise des librairies
3/ J'utilise Eclipse, qui est infichu de fonctionner en mode "projets/sous-projets" imbriqués
Si tu as des idées, je suis preneur
PS: crées un compte, ce sera plus simple pour éditer tes commentaires
- répondre
Renaud Bruyeron , le 9 October, 2007 - 10:13oops désolé pour le multipost, comme je ne voyais pas mes posts, je pensais que ca avait planté...
Pour mvn, il te faudrait un repository public (genre ce site web) et que tu fasses mvn deploy sur tes libs commons et xml. Comme ca tu peux te passer de "integration" et juste ajouter un repository dans le pom de tuxDroid
Sinon, j'insiste, il manque le folder bin/ dans le binaries.tar.bz2
- répondre
Ulhume, le 9 October, 2007 - 10:18Ah désolé, j'avais zappé cette remarque. Contrairement à ce qu'avance le README, il n'y a pas de bin dans le paquet binaries car il n'y a rien à lancer, c'est une API, donc à utiliser dans un programme de contrôle.
Si tu veux je peux te mailer une preview de la .4 qui elle contient une application de teste.
Pour ce qui concerne le repo, c'est une bonne idée. Faut que je couche un process propre sur le papier, je vais y réfléchir.
Ca fait des années que je développe des trucs en Java mais c'est la première fois que je rends cela publique, désolé pour les ratés.
- répondre
Septox , le 16 October, 2007 - 23:40Slt Ulhume,
juste que je voudrias bien bosser sur l'API java
- répondre
Ulhume, le 17 October, 2007 - 00:27@Septox
Comment ça python est une grosse pomme
))
Ben ecoutes pour bosser sur l'API java, c'est avec plaisir. Si tu veux, envois moi un mail a (en enlevant le bad_)
- répondre
Ulhume, le 17 October, 2007 - 08:14@Renaud
Normalement la version .4 est full maven compatible. Comme tu me l'a conseillé, il y a maintenant un dépôts des librairies tiers et le tout se compile par un mvn compile. Dis moi si ça colle chez toi !
- répondre
Bumblebee , le 7 January, 2008 - 20:31Salut,
Je viens d'avoir un joli tuxdroid pour noel et j'ai testé ton api .. le travail est impressionnant, mais après avoir mis à jour mon tux avec le dernier firmware ton API java a arreté de fonctionner. l'API python et tuxgi fonctionnent toujours normalement cela ne viens donc pas de ma bete. Aurais tu une idée d'ou cela pourrais provenir ?
Merci d'avance.
- répondre
Ulhume, le 13 January, 2008 - 15:09@Bumblebee Non, cela ne vient sûrement pas de la bête. J'imagine que le firmeware ayant changé, cela a cassé des choses de mon côté. Je vais flasher la mienne de bestile dés que possible et tenter de remettre une une nouvelle version à jour.
Merci du retour !!
- répondre
MRG58 , le 20 March, 2008 - 17:20Bonjour Ulhume et encore merci pour ces lignes de codes Java.
Continuant mon tour des OS pour gerer tuxdroid.
Apres Damnsmall et Ubuntu 7.1 et 6.06 qui fonctionnent normalement avec les api python et java, je me suis tourné vers 2 plateformes que j'utilise plus couramment soient xp sp2 et osX 10.4.9
Voyons voir xp:
Je vais faire un peu tâche d'huile dans le forum puisque j'ai recompilé en partie les API 4 et 5 pour les utiliser pour gerer tux sous windows avec le windows L&F donc.
Apres avoir recompilé tuxdaemon avec cygwin, le tuxletmanager V4 marche ok.
Mais pour la version 5 la console me renvoie une erreur de connection de Dbus, résultant en le non affichage des gadgets.
JAVA_HOME = C:\Program Files\Java\jdk1.6.0_04\jre
log4j:WARN No appenders could be found for logger (net.karmaLab.app.tuxletManager.TuxletManager).
log4j:WARN Please initialize the log4j system properly.
org.freedesktop.dbus.exceptions.DBusException: Cannot Resolve Session Bus Address
at org.freedesktop.dbus.DBusConnection.getConnection(DBusConnection.java:126)
at net.karmaLab.app.tuxletManager.dbus.DBusServer.run(DBusServer.java:59)
Etant plus instruit que moi concernant le mode de fonctionnement de ce serveur, aurais tu une idée pour résoudre ce problème?
En ce qui concerne OSX, je travaille avec un ppc G5:
et la derniere version java disponible est la 1.5.0_13-121.
Mais celle ci me renvoie comme erreur lors du lancement du bash pour les versions 4 et 5 de l'API:
Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
ce qui semble indiquer un pb de version trop faible de JRE mais malheureusement apple ne me permet pas actuellement d'evoluer.
J'ai essayé de recompiler par mvn mais un jac ver 1.6 est necesaire.
Donc je me tourne vers toi pour savoir si une idée tu aurais.
félicitations encore pour le travail de titan effectué et merci.
Marc du 58
- répondre
Ulhume, le 24 March, 2008 - 08:35Ahhh Apple le JDK, tout un programme
Le mieux est de recompiler l'ensemble et pour cela, pour cette version de l'API TuxDroid, il te faut Maven2. Pour la prochaine version ANT suffira. Mais pour l'instant, si ton environnement est correctement installé avec maven2, il te suffit de modifier le fichier .pom pour changer 1.6 en 1.5.
Pour ce qui est de Windows et DBus, effectivement les binaires natifs vont poser problème. Si tu es développeur, supprime la dépendance, elle ne touche qu'un ou deux fichiers. Sinon, la prochaine version de l'API sur laquelle je travaille ne va plus utiliser DBUS vu que le manager va dégager pour me recentrer sur la seule API, et le problème va donc être réglé de facto.
- répondre
MRG58 , le 2 April, 2008 - 15:25Merci pour tous ces bons tuyaux Ulhume:
J'ai deja testé la recompilation avec maven 2 sous osX mais je vais devoir reprendre toutes les sources pour recompiler les dependances aussi avec 1.5 (application et commons entrautre).
Pour Dbus, j'ai suivi tes precieux conseils, je me suis affranchi des dépendances avec Dbus et c'est OK.
Par contre, je n'arrive pas a trouver les sources du daemon tts pour les recompiler sur des plateformes differentes de celles d'origine.
Acapella n'est pas librement distribuée. Est ce que tu as expérimenté une autre bibliotheque (libre de preference) pour le tts (nvda par exemple).
Merci et encore bon codage pour la nouvelle API.
Marc
- répondre
Garf, le 19 April, 2008 - 12:35Salut Ulhume,
C'est Garf.
Merci pour tes réponses, juste pour info:
Pour le fun et pour faire rire les collègues
j'ai écrit, il y a quelques mois un tout petit programme java en ligne de commande qui tourne sous Windob
se connecte via le réseau sous une Linux Debian où se trouvent les daemons de notre tux favori.
J'ai donné le tux a une collègue et il s'est mis a lui parler bouger les ailes, les yeux etc...
La rigolade.
Du côté tech:
les pb rencontrés mais résolus: faire une boucle pour vérifier et attendre que les daemons puissent répondre, idem pour attendre le chargement de la voix.
J'ai tout de même une Question:
Au niveau des voix connais tu une astuce pour le changement de langues, il semble qu'il y ait des limitations au niveau hardware ?
Faut il arrêter redémarrer les daemons obligatoirement pour changer de langue ou bien peut-on charger une langue pendant l'exécution du programme (runtime) ?
Suggestion:
Indiquer que la boîte a outils et indispensable à l'API tuxjavadroidAPI0.5, il m'a fallu du temps pour réaliser pourquoi je n'arrivais pas a faire l'essentiel.
Ensuite je l'aie intégrée dans le programme et tout a fonctionné.
Je compte et cela quand je peux trouver un tout petit peu de temps dans mon agenda chargé, intégrer ta super API dans une servlet/webapp comme je l'indiquais il y a quelques mois, je sais à présent que c'est tout a fait faisable.
Merci de tes efforts et des réponses que tu pourrais apporter.
Bien Cordialement,
Garf
- répondre
Ulhume, le 19 April, 2008 - 13:07@Garf
Tu lui as donné, donné ? à ta collègue ou juste prêté ? Je demande cela car pour me femme, c'est maintenant officiellement le sien si tu vois ce que je veux dire 
Content de voir que cela fonctionne en tout cas
D'ailleurs si quelqu'un de chez TuxDroid passe par ici, elle pense que ce serait un bonne idée une ligne de fringues pour le Tux
Pour le coup des voix, je ne sais vraiment pas, je n'ai juste jamais essayé de basculer en temps réel d'une langue à l'autre. Je tente dés que je peux et je te dis ça.
Sinon, pour la suggestion, lorsque tu parles de la boite à outils, c'est à java-commons que tu fais référence ? Si oui, ok, je vais mettre cela en remarque.
Enfin pour la partie servlet, je te conseille d'attendre un tout petit peu. Ce n'est plus un secret vu que Remy (le développeur de l'API Python) en a parlé dans un post quelque part ici, la prochaine version des API a de fortes chances d'être full XML/RPC, avec une API Java en natif (que je vais peut-être réaliser) équipé d'un Servlet/Jetty en natif. C'est pas totalement officiel mais cela semble très bien engagé.
- répondre
Garf, le 19 April, 2008 - 15:59Prêter seulement
,
Je suis marié moi aussi mais ma femme prefere le côte obscure de la force
j'entends par là Zindob.
Tu pourras indiquer à ta moitié que c'est une idée bien cool.
Moi ce que j'avais fait pour donner du style à mon tux, c'est de découper un habillage en soie d'une bouteille de liqueur chinoise, puis je l'ai retirée car pour les mouvement c'était pas top ( j'avais un peu bâclé le travail ).
On habille bien les téléphones, alors pourquoi pas nos robots (poupées numériques ça fait pas bien masculin hehehe).
C'est sympa si tu peux faire le test pour le changement de langue au runtime
La nouvelle API:
L'idée de XML-RPC est très intéressante et signifie qu'il y aura un server XML-RPC quelque part a priori embarque dans une servlet si je comprends bien(mais j'en suis pas sur), mais j'aurai besoin de plus de détails là dessus.
En gros la question est:
Ou se trouvera le Server XML-RPC?
Pour ma part, ce qui m'importe pour développer sur le Tux c'est une couche serveur plus portable (un daemon java par exemple qui serait portable sur les différents OS car le boulot ne me permet pas d'utiliser le laptop avec Linux et je suis toujours en déplacements ) la problématique réside je pense dans l'implémentation de la communication USB avec Fux(le dongle) en fonction de l'OS.
La communication via XML-RPC client/server pourquoi pas mais je serai plus tenté de la faire en web services (SOAP) si l'idée est de permettre à différents langages de programmation de communiquer avec le serveur et vu le nombre d'outils permettant de faire des clients web services avec simplicité.
Ton initiative avec l'api java est très sympat, si j'avais plus de temps devant moi je me ferai un plaisir de la développer avec toi.
PS:par "boîte à outils" je faisais effectivement référence à java-commons.
Poster un nouveau commentaire