994 réponses à ce sujet

[Mike118]

Tu as changé quoi ?

[Oliver17]

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 ^^

[Oliver17]

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..

[Path]

Getty C ´est certainement la branche sur laquelle tu es assis. Ta comm continue de fonctionner quand tu le kill ?

[Oliver17]

Oui, ça fonctionne, j'ai viré le Getty avec la ligne de commande cité plus haut, du moins le ttyAMA0 et ça tourne.

 

j'ai rebooté plusieurs fois et c'est nickel.

[Oliver17]

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 .

[cocothebo]

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]

@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.

[Amhnemus]

Bien commenter tes lignes de code autant pour toi avant tout histoire de s'y retrouver et aussi pour les autres histoires qu'ils sachent ce que tu as voulu faire si les ligne de code ne sont pas clair

[Oliver17]

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 ^^

[Amhnemus]

Je fais pareil que toi j'etale sur papier et je vois tous ce dont j'ai besoin après je suis un noob du code mais le principal c'est que toi tu t'y retrouves

[cocothebo]

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.

[Oliver17]

Ok, encore merci Cocothebo, je ne vais pas ma lancer sur l'uml ^^

 

Je vais essayer de faire un truc "basique" sur papier, histoire de mieux m'organiser par la suite

[zavatha]

En tout cas j ai hate de voir les premieres videos car visuellement, ton robot, il deboite 😊

[Oliver17]

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

[Oliver17]

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 .

[R1D1]

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

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.

[Oliver17]

Cool pour la confirmation

 

aurais tu un lien mis à part celui que j'ai indiqué plus haut, genre tuto et autres exemples pour arduino.

 

Peut être que le lien plus haut suffit remarque.

[cocothebo]

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

[R1D1]

A priori ton lien suffit, si tu veux un exemple de code très simple (sans garantie de compilation ou fonctionnement réel parce que c'est vieux), tu peux regarder (auto-promo) mon repository robOStique : https://github.com/r1d1/robOStique(en anglais).
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, ...).