A mon avis la carte NVidia c'est overkill. 

 

Pour en profiter au maximum, c'est a dire utiliser toute la partie 'carte graphique', et pas seulement le CPU, qui en lui-meme n'a rien d'exceptionnel,  il va falloir programmer en CUDA, c'est de la programmation parallele, c'est deja accessible sur ton PC si tu as une carte NVIDIA ( y a des cours sur coursera si ca t'interesse), mais c'est pas de la programmation standard.

 

Moi je resterai sur ta config de base, et quand tu arriveras effectivement a une limite de performance, tu seras assez avance pour avoir une meilleur idee de ton besoin.

Il y a une fonction map en python. Mais ça ne fait pas du tout ca. C'est plus pour faire de la programmation fonctionnelle.
Mais il n'y a pas de fonction map en C non plus, juste une fonction map fournie avec la librairie Arduino.
Path a retrouvé son code exacte, c'est trivial à porter en python:

Sur le BeagleBone, tu vas tourner un vrai linux, ( comme le raspberry Pi), donc ce n'est pas une programmation temps reel. En particulier ton programme ratera des evenements venant des GPIO si ils sont a une trop grande frequence, surtout des que ton programme fait du vrai traitement avec.

Par exemple il n'est pas realiste de faire un encodeur en quadrature avec les GPIO d'un beaglebone ( ou d'un raspberry PI d'ailleurs), j'ai teste, j'ai fail.

Sur le beaglebone il y a par contre deux autres processeurs temps reels, qui eux peuvent etre utilise pour ce genre de traitement d'input a haute frequence ( 100Mhz max je crois), mais la programmation c'est plus proche de l'assembleur que du Python.

 

J'ai un beaglebone et j'ai fait des choses avec, mais pour l'instant je suis revenu a la combinaison raspberry PI + arduino, c'est plus simple a programmer.

Voici 5 videos du cours  "ColumbiaX: CSMM.103x Robotics" que je suis sur edx.org (https://www.edx.org/...mbiax-csmm-103x)

C'est en anglais malheureusement.

 

Ca explique la notation D.H et son utilisation pour faire de la forward Kinematic :

 

Forward Kinematic D.H Example:

 

D.H Notation example : 2-link planar robot

 

D.H Notation example : SCARA Robot

 

Kinematic example : 6 DOF and 7 DOF robots :

 

 

Autre projet plus ou moins realisable soi-meme :

Nybble

https://www.indiegog...en/x/20356453#/

 

Galileo est techniquement plus precis, mais je ne sais c'est pas si la précision maximale est déjà activée, et à quel point elle est accessible.

Par contre les satellites sont placés pour optimiser la triangulation sur l'europe, là ou le GPS est optimisée pour la triangulation sur les US ( et glonass sur la Russie).

Donc en règle générale il y aura plus de satellite visible, et une bonne précision nécessitera moins de satellite visible quelque soit l'augmentation de précision des satellite eux mêmes.

Joli résultats ! C'est toujours motivant de se voir selectionné comme ça, et en plus avec une récompense c'est vraiment cool !

La classe le diagramme !

Tres joli pour montrer et expliquer aux autres ( et peut-être d'y retrouver soi-même

Tu peux aussi utiliser le protocol I2C.

Si le raspberry  est en maitre et les arduino en esclave il n'y a pas besoin de convertisseur logique.

Voici ce que j'ai trouvé sur le sujet :

https://oscarliang.c...-connected-i2c/

Courage ! Moi aussi j ai un peu revu mes ambitions a la baisse sur chacun de mes projets, sinon ca n avance pas et ca demotive un peu.

Questions, qu est ce que tu utilises comme batterie 12v ?

Le support servo et la 'tourelle' c'est de l'impression 3D ?

Et les deux plateaux transparents au milieu et en haut du robot, quel materiel tu utilises et comment tu le travailles ?

Ah cool , faut que je me fasse un setup similaire pour creer tous ces elements de support non structurel.
La perceuse avec support, plus des plaques de bois ou plexi me parait un bon setup simple efficace, pas cher et pas trop encombrant.

J'ai regarde les differentes license creative commons.

Vu ce que tu decris, ce que tu veux choisir comme license c'est Creative Commons-Attribution.

C'est la license la moins restrictive, la seule contrainte pour un utilisateur c'est de te citer comme contributeur original s'il reutilise ton travail de quelque maniere que ce soit. Par contre il peut tout faire avec ta contribution, la modifier, l'integrer, la diffuser, la vendre. etc.. , pas de restriction.

Je ne connais que les licenses pour software, donc pas les creatives commons.

Mais la GNU-GPL est loin d'etre sans contraintre, c'est plutot le contraire, c'est une license 'virus' : pour include du GPL dans ton projet, ton projet doit etre lui-meme GPL ( si tu le publies bien sûr)

La GNU-LGPL limite un peu ce probleme de 'virus'.
En software les licenses les moins contraignantes sont les licenses de type BSD, MIT. Tout ce qu'elles imposent en gros c'est de devoir indiquer que tu as utilisé ce code, et donner la license d'origine pour cette partie.

Impressionant les resultat de l'algo de localisation, est-ce que c'est novateur au point d'en faire un papier à publier ?

En python, la reference c'est numpy, mais tu n'es pas en python

En faisant ma petite recherche "numpy equivalent in c++", je pense effectivement que eigen semble la reponse la plus frequente.

L'un des points en sa faveur, c'est qu'il y a des bindings vers eigen dans openCV, ce qui veut dire que c'est une librairie utilisee et activement supportee.

Le teaser !!

Dernièrement j'utilse Olive, une appli open source qui même si elle est en 'alpha' fonctionne très bien pour toutes les manip de base ( copié/découpé/fondu ).

 

https://www.olivevideoeditor.org/

Bah non tu n'as pas l'air fin du tout avec ton rateau et ton sable, tu affrontes des problemes different, par exemple mecaniques, pour lequel tu cherche des solutions, certaines meilleurs que d'autres, et c'est ce processus qui est tres interressant a entendre.

J'avoue que j'ecouterai ton interview avec attention si elle a lieu, pour justement suivre le cheminement du projet avec les problemes que tu as rencontre, leurs bonnes et leurs mauvaises solutions. Car j'ai ou je vais rencontrer des problemes similaires aux tiens, pour lesquels tu as trouve des solutions, que tu trouves peut-etre parfois anodines, mais auxquels j'aurais jamais pense, ou qui permettront de me confirmer que c'est un bon ou un moins bon choix.

Je trouve que le format audio correspond bien a ce que tu es en train de demarrer. La video c'est tres complique a monter, surtout pour des formats de 10 min ou plus, c est aussi tres contraignant pour les intervenants.

Personnelement je suis partant pour aider a animer une emission, je suis plus a l aise pour repondre, commenter, rebondir que vraiment pour ´leader' une emission. J'aime bien l'idee de reprendre des sujets du forum (avec autorisation de l'auteur initial) et d'en extraire les parties interressantes, et de les discuter en live, avec nos connaissances/meconnaissances respectives. Pour les questions de debutants, a defaut de trouver des personnes pour poser leur questions en live, ou de les poser sur le repondeur, on peut peut etre aussi reprendre des questions simples poser sur le forum (avec autorisations).
On peut aussi imaginer une petite section ´nouvelle du monde la robotique ´ ou l' on reprend une/deux info d'actualite sur la robotique et on commente un peu. Ca mixerai du contenu technique avec un peu de contenu d actualite.

Je préférerai commencer en bi-mensuel, parce que j'aime bien preparer, et si ca devient trop contaignant a mon gout je risque de lacher en route un peu sans prevenir. Quitte a passer en hebdomadaire quand j'ai trouver mon rythme et ma zone de confort.

Oui a priori la pin D0 sert a une connection interne special :

 

 

GPIO16 : Belongs to the RTC module, not the general GPIO module, so behaves differently

 

Sinon j'ai trouvé ce lien qui propose un possible bout de code pour driver le GPIO16 :

https://github.com/e...uino/issues/123

C'est clair qu'il a une très belle allure ce robot !

Le problème de faire juste 'bord gauche plus pret que bord droit' c'est que tu es très sensible à toute imperfection de ton capteur (et de la piste), et tu peux passer ton temps a tourner a gauche, tourner a droite et ne pas avancer.

Personnalement je commencerai avec un algo a hysteresis :

Si le rebord gauche est <MinG cm je tourne a droite jusqu'a ce que le rebord gauche est >MedG cm.

Si le rebord droit est <MinD cm je tourne a gauche jusqu'a ce que le rebord droit est >MedD cm.

Sinon je vais tout droit

Ca va quand meme faire des zig-zag, mais en calibrant bien MedG et MedD tu devrais pouvoir avancer a une bonne vitesse globalement.

 

 

Apres si tu sais controller ton robot pour le faire tourner avec different rayon de courbure alors tu peux regarder a faire des controlleurs plus complique derivant le rapporchement des bords ( plus je me rapproche vite du bord, plus je tourne 'fort'). Mais tu n'en es surement pas à ce niveau de controle du déplacement de ton robot.

En intelligence artificiel , on parle de plusieurs type d'agent du plus simple au plus complexe :

1. Agent 'simple réflexe'
2. Agent 'réflexe basé sur un modèle'
3. Agent 'orienté objectif'
4. Agent a apprentissage

Les catégories peuvent être plus étoffée suivant les écoles.

La quantité de puissance de calcul requise pour chacun de ces agents augmente exponentiellement avec leur complexité.

 

Avec un Arduino tu peux faire des agent 1) certain 2) si le model est simple, certain 3) si l'objectif est simple.

Avec un Raspberry PI tu peux faire des agents 1),2) 3) et certains 4).

 

Dans la catégorie 4) les agent les plus complexes demande des puissances de calcul tel que même un  ordinateur ne suffit pas, et donc il faut utiliser des fermes de calcul, souvent accédée via le 'cloud'

C'est le cas par exemple des intelligences artificielles de type 'Siri', 'Ok Google', 'Alexa', l'analyse et le traitement des requêtes vocales partent dans le cloud,

Je viens de tomber sur une ressource nouvelle pour moi, c'est en anglais, mais il y a l'air d'y avoir toutes les categories possible.

 

https://robotacademy.net.au/

 

Vous connaissiez ?