Tu as changé quoi ?
Glenn Robot Humanoide
#641
Posté 08 décembre 2017 - 10:37
Si mon commentaire vous a plus laissez nous un avis !
Nouveau sur Robot Maker ?
Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope aux articles, à la boutique et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être !
Si vous souhaitez un robot pilotable par internet n'hésitez pas à visiter www.vigibot.com et à lire le sous forum dédié à vigibot!
#642
Posté 08 décembre 2017 - 10:44
Coucou Mike, bon je crois que j'ai réussi à virer le bignou :
sudo systemctl disable serial-getty@ttyAMA0.service
C'est ça apparemment qui prenait des ressources, fallait le desactiver.
J'ai refais un test de com avec le prog et ça fonctionne toujours
J'ai rebooté plusieurs fois et ça a l'air d'être bon ^^
#643
Posté 08 décembre 2017 - 11:37
Bon et bien il me reste plus qu'à m'organiser pour la programmation de savoir qui va ou (pi ou arduino, mais j'ai déjà commencé) et y allez doucement module par module, je sent que j'ai pas fini, en même temps, je pense que c'est l'une des parties les plus intéressantes, (en fait c'est la partie perte de cheveux)
Si vous avez des conseils au autres (sur l'organisation, votre façon de voir les choses), suis preneur, déjà une question me vient, c'est de créer plusieurs programmes sur arduino :
- un pour l'écran oled
- un pour le driver maestro
- un pour le capteur de distance
- éventuellement tester avec une led aussi pour tous ça.
Pour l'instant c'est déjà pas mal de tester avec ça.
Mais tous ça, sans que cela soit mélanger sur le même programme, que des programmes séparés que l'on interroge lorsque l'on en a besoin..
#644
Posté 08 décembre 2017 - 12:51
#646
Posté 11 décembre 2017 - 10:26
Plop les Maker's, afin de bien faire et de partir sur de bonne base, avez vous une façon de travailler pour votre code, ou codez vous à l'arrache comme des barbares directement ^^
Pour l'instant je place les grandes lignes sur papier de qui fait quoi et qui va ou...
Mais par la suite, il y a t'il une sorte de protocole, une façon de faire à respecter pour que toutes personnes relisant mes notes puissent si retrouver, ou autre ?
Edit : utilisez vous UML pour la POO avant de commencer à coder ???
Merci
Modifié par Oliver17, 11 décembre 2017 - 10:47 .
#647
Posté 11 décembre 2017 - 10:49
Salut,
Moi je ne code plus c'est plus simple
Sinon pour moi pas de secrets, si tu fonctionnes avec un lanagage objet il faut bien travailler le découpage en classes pour avoir qqc de "léger". Ce que je veux dire c'est que même si certains traitements sont très complexes, s'ils sont "cachés" par un appel de méthode (avec un nom compréhensible) sur une classe dédiée, ça permet à la lecture de comprendre rapidemment ce que ça fait sans rentrer dans les détails.
Par exemple, le code pas trop optimisé d'une fonction crypto genre AES est pas si simple à comprendre, mais si tu as juste un appel genre
myCryptoEngine.encryptAES(...)
n'importe qui comprendra que c'est un chiffrement AES, de même si les paramètres sont clairs, ça permet de savoir ce qui est vraiment processé:
myCryptoEngine.encryptAES(buf1, buf2, buf3, buf4, 1, 0)
reste compréhensible sur la fonction elle même mais les param ne vont pas aider à comprendre, alors que (par exemple):
myCryptoEngine.encryptAES(myAESKey, IV, bufferToEncrypt, result, AES_CBC_MODE, AES128)
sera plus parlant, on voit ce que l'onchiffre, avec quel algo etc. (bien sur qqu ne connaissant pas du tout la cryptographie ne comprendra pas tout).
dans mon troisième exemple, j'utilise des constantes qui permettent de nommer des paramètres de façon compréhensible, genre AES_CBC_MODE (correspond au 1 du deuxième exemple), là on voit que c'est de l'AES avec un mode de chainage CBC (certes faut savoir ce qu'est un mode de chainage).
Bref plus on met d'abstraction, plus le code est lisible (sous réserve de bien nommer ses variable, constantes et méthodes), mais faut pas non plus tomber dans trop d'abstraction sinon ça devient casse pied à suivre, genre
maClasseMagique.maFonctionQuiFaitTout(...)
obligera d'aller dans cette classe et méthode pour voir ce qui se passe.
Le deuxième point c'est de commenter le code même si il est de tradition de dire qu'un code clair n'a pas besoin de commentaires, c'est toujours bien d'en mettre, le mieux à mon avis reste à minima de mettre des entête par classe et méthode genre doxygen ou javadoc qui permet d'extraire une documentation utilisateur des interfaces (en gros ce que fait chaque classe, méthode, description des constantes etc) mais ça demande quand même pas mal de boulot.
Ne pas oublier de mettre par contre des commentaires dans le code pour chaque "hack" ou lignes de codes qui ne seraient pas trop standard ou usuelles. Par contre commenter chauque ligne ou presque est inutile, je considère qu'il faut commenter pour que quelqu'un qui connaisse déjà le langage et les APIs s'y retrouve, ce n'est pas un tuto ou autre.
- Oliver17 aime ceci
#648
Posté 11 décembre 2017 - 10:55
@Cocothebo : ok, c'est déjà un début, donc faire attention à bien nommer classe et méthode pour que cela soit compréhensible, R1D1 si je me rappel bien m'avait déjà prévenu sur cette partie, et ok pour les commentaires.
Si vous avez d'autres suggestions suis preneur, c'est surtout histoire que j'arrive à me faire comprendre lorsque vous me demandez un truc ^^ vu que j'ai du mal par moment lol
Puis c'est aussi pour bien faire, autant faire ça proprement.
Merci.
#649
Posté 11 décembre 2017 - 11:01
#650
Posté 11 décembre 2017 - 11:20
Oui c'est ce que disait Cocothebo, plus haut
Ce que je voulais dire, c'est que par exemple lorsque je bossais dans le jeux vidéo, pour chaque jeu il fallait établir un GameDesign, avec ça tu retrouvais tous ce dont tu avais besoin pour développer le jeu, (de l'histoire, des commandes, interactions etc etc etc...), je pensais qu'il y avait un système dans le même genre pour la robotique, comme déjà dis, pour l'instant j'ai mis sur papier à peu prés tous ce dont j'avais besoin, d'un coté la pi et se qui va tourner dessus, (cam, (plus tard micros), en code les algos et la communication), sur Arduino tous les capteurs (IMU, capteur chaleur, de luminosité, driver maestro, une Led RGB, Ventilos, écran oled, et un capteur de distance), en code pour Arduino, si c'est faisable c'est de faire plusieurs "modules" (manque de jargon désolé), ex : IMU avec sont code, l'écran avec sont code, etc etc, et donc, Pi fera appel à ces fichiers lorsqu'il en aura besoin suite aux données envoyé par Arduino et au calcul effectué par la Pi.
Bon, dans ma petite tête c'est une façon grossière de voir les choses, mais peut être que je m'y prend mal, ce n'est peut être pas la bonne façon de procéder, donc en gros comment établir tous ça sur papier dans un premier temps...
...suis je suis la bonne voie
Merci ^^
#652
Posté 11 décembre 2017 - 05:00
Ah ok, moi je parlais plutôt de documentation fonctionnelle, toi tu parles ici plutôt d'architecture du logiciel.
Sur ce point, je ne sais pas si des méthodes existent pour décrire "correctement" une architecture, j'avoue que ça reste compliqué, surtout pour faire une description a priori (la description a posteriori est facile elle )
Dans le monde de la sécurité informatique, une base a été définie pour un référentiel (presque) commun pour évaluer la sécurité d'un produit, ça s'appelle les Critères Communs (ou Comon Criteria en english), une demande est justement d'avoir ce type de documentation (spécification fonctionnelle et de design), mais la méthode pour construire ces documents n'est pas décrite il me semble. Souvent la spécification d'archi ou design est faite a posteriori et décrit les interfaces avec leur éventuelles implication sécuritaires (parce que c'est pour faire des évaluations de sécurité).
Si on lie ce post avec celui sur l'UML qui me semble être la même question, oui un bon diagramme UML permet de décrire un système, mais c'est vite complexe et incompréhensible en fait.
#654
Posté 14 décembre 2017 - 08:23
#655
Posté 14 décembre 2017 - 08:59
Merci pour le visuel et encore atta de voir lorsque j'aurais fais toutes les découpes pour l'impression, mais bon, je pense que le plus intéressant tout de même et ce qui touche à la programmation ^^
Donc si c'était aussi facile pour moi de programmer que je modélise, ce serait le bonnard ^^
Pour l'instant et grâce aux gars, je peux communiquer entre arduino et pi en c++ via le Tx/Rx, chose que je trouvais important à réussir pour la suite...
...et donc je m'amuse avec les capteurs, drivers, écran oled et j'essaye de mettre sur papier de quelle façon coder tous ça
Ça avance, doucement, mais ça avance
#656
Posté 15 décembre 2017 - 09:21
Coucou les Maker's, peut on faire de la POO avec arduino ??
Si oui, il y a t'il une méthode particulière, ou cela se comporte t'il comme pour du C++ ??
Edit : j'ai trouvé ça, je ne sais pas si la piste est bonne.
http://www.vorobotics.com/wiki/index.php?title=Adafruit-multi-tasking-the-arduino-part-1
Merci
Modifié par Oliver17, 15 décembre 2017 - 09:38 .
#657
Posté 15 décembre 2017 - 11:17
Oui, tu utilises la POO à chaque fois que tu crées une instance d'une classe (#include <Servo.h> e.g. Servo cou;), et tu peux définitivement organiser ton code en classes. Le langage Arduino est dérivé du C++ et permet ce genre de choses.Coucou les Maker's, peut on faire de la POO avec arduino ??
Si oui, il y a t'il une méthode particulière, ou cela se comporte t'il comme pour du C++ ??
Edit : j'ai trouvé ça, je ne sais pas si la piste est bonne.
http://www.vorobotics.com/wiki/index.php?title=Adafruit-multi-tasking-the-arduino-part-1
Merci
- Oliver17 aime ceci
#659
Posté 15 décembre 2017 - 11:42
Salut,
En exemple de classes pour arduino (donc en C++), le plus simple c'est d'aller dans l'API, toutes les APIs style servo ou autre sont des classes et donc en cherchant le servo.h et .c tu as des exemples fonctionnels de classes "arduino" , pour l'utilisation ben un sketch genre pour l'utilisation des servomoteurs dans les exemples de l'IDE et c'est tout bon
- Oliver17 aime ceci
#660
Posté 15 décembre 2017 - 03:23
J'avais commencé à organiser en classe du code écrit et/ou tiré des exemples que j'avais pu trouver ça et là.
En plaçant ce code dans le dossier "librairies" de l'IDE, tu peux ensuite faire un " #include <robOStique.h> " (ou en remplaçant < > par " " si ça marche pas) et avoir accès à toutes les classes ainsi déclarées.
Tu pourrais par exemple embarquer le code qui fait la communication série côté Arduino dans une classe, puis dans ton sketch principal, créer un objet de cette classe et l'utiliser (init, update, ...).
1 utilisateur(s) li(sen)t ce sujet
0 members, 1 guests, 0 anonymous users