Pou les fans d'hexapode celui la est pas mal au niveau de vitesse et de la capacité de déplacements :

 

 

Ce n'est malheureusement pas la suite de l'EV3, étant orienté pour des enfants plus jeune, mais c'est toujours mieux que rien.

Ca formera les prochaines générations !

 

Je suis en train d'écrire un tutoriel pour l'ensemble arduino/raspberry/PC.
C'est assez long à écrire donc j'ai fait une sauvegarde en copier/collant le contenu de ma page en cours de construction dans un fichier pour plus tard.

Je voulais voir s'il y avait une méthode plus simple, en soumettant le tutoriel 'en cours', pour pouvoir l'éditer plus tard, avant de dire qu'il est pret pour publication ?
J'ai pas oser appuyer sur 'soumettre' de peur de pas pouvoir édtier, ou qu'il soit visible en l'état.

Je pense aussi que ton ami américain a raison, aller à l'international ne coûte pas plus cher, surtout ramener à la somme levée si :

• Tout le monde dans l'équipe comprends l'anglais, et plusieurs sont assez "bilingue"
• Le fait d'être franco-francais est une grosse valeur ajoutée du produit. Parce que tu cibles gens qui recherche du 'local' par exemple.
• Tu ne cherches pas des partenariat avec des institutions françaises
• Le support du produit ne nécessite pas de localité.

Dans ce que j'ai vu de Vigibots / Vigirobots, je ne croit pas voir d'argument contre l'internationalisant directe, surtout que même en france, les premières cibles seront très surement anglophones.

Après entre indiegogo et kickstarter je n'ai pas d'avis, je soutiens des projets sur les deux plateformes, et je n'ai jamais soumis de projet.

Voici mes reponses, a ces questions :

1.
On peut decomposer un robot en 4 parties :

a. Les 'actionneurs', c 'est a dire les moteurs et tout ce qui permet d'interagir avec son environment.
Donc dans une voiture on a le moteur principale, assez difficile a utiliser. Mais on a aussi les moteurs de leve-vitres, les moteurs d'essuie-glace, qui eux peut faire des robots, mais plus petit.
Doit y avoir des moteurs pour freiner et tourner pour toi dans les voitures autonomes.
Un robot genre 'transformers' de la taille d'une voiture ne peut pas vraiment etre construit a partir d'une voiture je pense, pas assez d'actionneur. En tout cas, pas la version 'bipede'

b. Les 'senseurs' tout ce qui permet de s'informer de l'environment. Dans une voiture il y en a plein, et de de plus en plus avec les voiture autonome. Capteur de pluie, capteur de lumiere, capteur de choc, detecteur de distance, camera de recul etc.

c. La mecanique : tout ce qui fait la forme, la 'flexibilite' et l'allure du robot. La avec une voiture il y a de quoi faire. 

d. Le cerveau. En regle generale c'est un 'ordinateur'. Mais dans les voitures modernes la console interactive avec le gps la musique etc contient un bon 'ordinateur' suffisant pour faire un cerveur d'un robot pas trop complexe.

 

Faire un robot a partir d'une voiture c'est globalement pas abherrant, mais le robot sera plutôt roulant que un bipède humain. D'ailleurs les voiture dites 'autonomes' sont des robots.

 

2. Oui on peut tout a faire imaginer faire un robot roulant se servant de roue de velo.

 

3. Effectivement les roues c'est beaucoup plus simple que des jambes. Mes les jambes sont beaucoup plus adaptes a un environnement varie. Pour te faire une idée, regarde toutes les difficultés qu'ont les personnes en siège roulant pour se déplacer dans notre environnement urbain.

 

4. Le cerveau du robot c'est un ordinateur, plus ou moins complexe. Un smartphone contient deja la puissance de calcul pour faire un cerveau de robot tres intelligent.

Les boards sont propriétaires, mais chacune est compatible arduino, dans le cas de l'ultimate 2.0 c'est le MegaPi qui est compatible Arduino. ( et pour la MegaPI c'est directement connectable comme un 'hat' de raspberry )

Toutes les bibliotheques de programmation sont fournis et lisible, on peut donc s'en inspirer pour écrire sa propre version, ce que je fais pour mon robot auto-equilibré a balancier.

La connectiques des moteurs avec encodeurs est standard, le moteur du shop d'ici est d'ailleurs compatible

Les sensors sont montés sur des cartes avec une connectiques de type RJ25, mais dont la description est ouverte. Et il est tout a fait possible de s'en passer, ils ont d'ailleurs un petit module qui 'publie' les sorties I2C et des sorties analogique de la méga, pour rajouter ses propres senseur ou actionneur (http://www.makeblock.com/me-rj25-adapter)

 

Dans l'ensemble je trouve que ca n'enferme pas, ca propose leur solution pour avoir des kit tout-en-un facile a assembler, mais derrière on peut étendre a sa sauce.

J'ai aussi l'EV3 de Lego et là tu es vraiment dans un truc propriétaire et enfermant.

 

Coté pur mécanique, c'est moins complet que les ensembles comme 'actobotics' mais c'est un peu moins cher, et surtout c'est aux cotes métriques et pas aux cotes impériales ! C'est aussi un peu plus facile a trouver en France.

J'avais vu que pour les trucs très simples il existait 'MIT app inventor' pour faire des apps sans faire de programmation.
Mais le bluetooth c'est deja peut-etre trop avance pour l'app inventor, et on a ici sur le forum le niveau en programmation pour utiliser android studio

D'un autre coté, si vous voulez un testeur pour un Ultimate 2.0, je suis probablement partant, en avoir un deuxieme ne me pose pas de probleme, meme si c'est juste 25% de reduction

L'ultimate 2.0 etait introuvable en France lorsque j'ai voulu l'acquerir, or il me parait nettement mieux que l'ultimate, rien que pour le robot autoequilibré qui fonctionne magiquement bien !

C'est vraiment un meccano pour les adultes et l'utimate 2.0 fournit suffisament d'élément pour nourrir l'imagination.

 

Ceci étant j'ai déjà le mien, donc je ne serai pas le premier acheteur.

Merci pour ces détails supplémentaires, je pense qu'à la fin de ton test les infos utiles seront repris sur la page du shop.

 

Les trous de fixations sont de quelles tailles ?

 

Je pense que ca va m'interresser, pour pouvoir afficher l'état de mes robots, sans toujours passer par le log du bluetooth.

Cool le T-shirt sur la boutique !

Va falloir que je repasse commande a la boutique alors.

Non mais maintenant je me force a cliquer sur la boutique de temps en temps et a regarder la liste des nouveaux produits. Et j'ai vu les ajouts recents avant ce poste.

 

La je commentais pour dire que c'etait cool d'avoir les T-shirt sur la boutique.

Tu n'as pas de solution pour quoi ?

 

Si tu veux voilà un petit exemple que je me suis fait pour tester l'écran, je ne suis pas aller beaucoup plus loin que cela pour l'instant.

 

 

https://github.com/B...D/Test_OLED.ino

Il a des allures de pokemon !

Double vote !

Je trouve effectivement les résultats de recherche très pertinent ( sur les tests que j'ai fait), surtout, ca gère bien les typos et ça, c'est le bonheur, pour moi

Et si les 4 annonces de début sont le prix à payer pour avoir une accès à un outil de recherche de ce niveau, ca ne me gène pas.

Pas de probleme pour mettre des updates, au contraire, comme ca la communaute peut suivre, commenter si elle en a envie, et en plus souvent ca garde la motivation pour celui qui post.

 

Tu as l'air d'avoir une idee en tete qui te semble raisonnable, je te conseille de la mettre en oeuvre. Peut-etre qu'elle ne marchera pas parfaitement, voir pas vraiment, mais parfois il faut affronter quelques aleas pour avancer, pour se faire une idee des contraintes ou problemes qu'on avait pas imagine. C'est un premier prototype !

Il peut y avoir un  interet à avoir des microcontrolleurs multiple dans une même application, et pas seulement pour des problèmes de localisation.

C'est pour séparer les problèmes, comme en language objet, quand tu commences a faire des classes séparés. Le micro-controlleur dédié à l'analyse des encodeurs, au calcul de vitesse et évaluation de position tu peux décider de le séparer comme ça plus besoin de reccompiler, et les modifications sur les autres microcontroleur ne peuvent pas baver sur celui-là.

D'ailleurs la majorité des gros capteurs ( par exemple le BNO055 ), viennent avec leur microcontrolleur dédié, pour masquer le détail de la conversion du signal analogique des capteurs en des données digitales un peu plus haut niveau.

 

Après, dans nos réalisation personelles où l'on concoit pas des cartes, mais plutôt assemble des composants, les micro-controlleurs sont 'gros', car ils viennent avec beaucoup de feature inutile une fois mis en place. ( programmeteur par exemple, port USB etc..).

Ceci étant, un arduino nano, c'est assze petit, et parfois séparer certains problèmes matériel en deux pourrait faciliter le développement.

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 ? 

Cela va toujours plus lentement que ce qui était prévu initialement, pour tout le monde, même les gens expérimentés.
Donc c'est normal et personne ici ne va s'en étonner, le plus important c'est de continuer régulièrement.

Pour la cinématique inverse, y a MoveIt ! qui fait partie de ROS :

http://moveit.ros.org/

 

Cette librairie fait beaucoup de chose. Cinematique inverse, plannificateur de mouvement etc..

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.

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.