Salut,

Le langage arduino est effectivement un sous ensemble de C++.

C'est très souvent utilisé sans spécialement utiliser le côté orienté objet du C++ et donc on retombe sur plus ou moins du C, mais il faut savoir qu'on peut programmer orienté objet plus tard

(avec par contre des restrictions comme pas d'exceptions de mémoire)

Pour la comparaison avec le C, je ne vois pas spécialement de grosses différences, les pointeurs existent, le malloc etc aussi. La "grosse" différence avec du code C d'école ou sur ordinateur vient de trois choses:

1. on est sur de l'embarqué, donc pas les mêmes habitudes de prog, par exemple il faut penser à travailler énormément avec les interruptions, pas beaucoup de mémoire, etc.
2. l'API fournie n'est pas la libC, mais comporte bcp de choses (faites pour être simples à utiliser)
3. le programme en lui même se fait en gros dans deux méthodes "setup" et "loop" (et sans utiliser de main) qui en gros vont se comporter comme

int main(...)
{
  setup();

  for(;;)
    loop();
}

A priori, arduino a été fait dans l'optique de rendre accessible la programmation en C/C++ à des artistes ou autres (comme avec Processing ou Wiring).

Bon courage pour la découverte de ce monde merveilleux!

Bonjour,

Par défaut deux moteurs identiques ne le sont que très rarement, en gros ils ne tournent pas exactement à la même vitesse pour la même tension d'alimentation.

Donc il faut avoir un système qui te permette à minima de t'assurer que les deux moteurs tournent à la même vitesse (bref un asservissement quelconque de la vitesse de rotation), être sur que tes deux roues sont du même diametre (sinon faut ajuster l'asservissement).

Une fois cela en place, ton robot n'ira peut être toujours pas droit si une roue glisse plus que l'autre, donc il te faudrait aussi être sur que les roues ne glissent pas.

bon courage

Salut,

Moi dans une optique "DIY", j'utiliserais la roue telle quelle (que ce soit roller ou skate).

Tu laisses le roulement au centre de ta roue, tu la mets sur un axe 8mm, tu as donc une roue libre sur l'axe (bref une roue de roller quoi )

Tu rajoutes une couronne (grosse roue dentée quoi) quelconque en la fixant a travers la roue (3 trous que tu vis à travers la roue + celui de l'axe en >10 mm) et en sortie de ton moteur un pignon en contact avec la roue dentée.

Ca te permet plusieurs choses interessantes:

1. une possible démultiplication entre la sortie moteur et la vitesse de ta roue (pour gagner en couple par exemple)
2. eviter d'avoir le moteur en prise direct sur l'axe de la roue, ça évite des efforts inutiles
3. c'est facile a faire sans materiel trop avancé (si tu veux que ca tourne rond, une peceuse colonne reste quand meme nécessaire)
4. ca ne rajoute pas énormément de frais
5. pas d'accouplement d'axe à faire

Bref moi je pense que ça reste une bonne solution relativement simple à mettre en oeuvre et si jamais tu devais déporter un peu plus tes moteurs des axes, le même systeme avec une chaine (ou courroie) fonctionnera pareil.

Bonne continuation

Bonjour,

Je comprends pas exactement ton "architecture", pour résumer tu souhaites diriger ton robot à distance en utilisant un lien "internet", c'est bien ça?

Si ma compréhension est bonne, je suis etonné que tu fasses un server.accept() a chaque tour de boucle, si je comprends bien la doc succinct de cette fonction, ça ouvre une connexion depuis ton serveur.

Il suffit de l'ouvrir une fois et après d'attendfre des commandes (à voir si ya du time-out) et avoir une commande de déconnexion. Quand tu n'as pas de client tu attends alors une connexion mais dès que tu es connecté tu n'ouvre plus de nouvelle connexion, juste tu processes les commandes.

La ça me semble être une implémentation style "serveur web" qui balance la page qui va bien à un client, dans ton cas tu n'as pas besoin de gérer plusieurs clients en même temps, mais un client et des commandes pour ce même client (on peut donc garder la connexion ouverte).

Moi j'essayaierais de mettre en place un algo du style:

     1. tant que pas de connexion, j'attends une connexion

     2. tant que pas de commande j'attends une commande

     3. procésser la commande recu

     4. retour au 2 (ou 1 si commande de déconnexion)

C'est un algo vu de très haut et très simpliste, mais au moins ça te permet d'avoir des "sessions" qui évite de refaire des connexions en permanence, l'établissement d'une connexion reste couteux donc autant les éviter le plus possible.

Bien sur ce que je dis là s'applique si le server.accept() ouvre une nouvelle connexion à chaque passage, si en cas de connexion déjà ouverte ça ne réouvre pas c'est caduque.

Après pour continuer à optimiser un peu, il faudrait aussi travailler sur protocole en lui même, l'envoie de string de commande "human readable" est certes pratiques pour le debug ou autre mais vraiment pas optimal, tu as un set d'une dizaine de commande, autant envoyer juste un octet (par exemple 00h pour stop, 01h pour forward etc.) qui sera plus facile a "comprendre" pour ton pogramme. Il faudrait tester pour voir mais le readString est surement couteux, la comparaison sur les strings aussi.

Dans l'absolu pour gagner le plus en temps il faudrait fonctionner avec des pointeurs sur tes fonctions "stop", "forward", etc., ça permet d'éviter de tester les valeur, en gros tu stockes un pointeur de chaque fonction dans un tableau, et quand tu recois ton octet, tu vérifies qu'il est dans le bon range (pas négatif et pas plus grand que ton tableau) et tu execute directement la fonction à l'index de ton tableau.

A voir si c'est possible en arduino mais il me smble que oui.

par exemple: (ça doit fonctionner mais n'ayant pas d'arduino sous la main j'ai pas testé)

//tu créés un type "pointeur sur fonction"
typedef void (*FunctionPointer) ();

//tu créés ton tableau de pointeur de fonctions
FunctionPointer commandes[2] = {stop,avance, recule};


//les méthodes sur lequel on pointe
void avance() {
  myStepper1->setDirection(LOW);
  myStepper2->setDirection(LOW);
  myStepper1->start();
  myStepper2->start();
}
void recule() {
  myStepper1->setDirection(HIGH);
  myStepper2->setDirection(HIGH);
  myStepper1->start();
  myStepper2->start();
}
void stop() {
  myStepper1->stop();
  myStepper2->stop();
}


void loop() {
  //[...] metre en place ce que tu veux, la connexion etc.

  // On rçoit la commande
  icom = client.read();
  
  //on check le range, je considère que c'est signé, on doit pouvoir optimiser
  if (icom > 0 && icom < 2) {
     //on traite la commande
     commandes[icom]();
  }

  // [...] tu finis le traitement
}

Dans le cas d'un protocole du genre, ca te permet d'aller très vite sans faire de comparaison, ça amèliore donc forcément la latence, ca te gagne aussi un temps d'exécution a peu prêt constant que tu utilises la premier ou la derniere commande

Si on prend ton algorithme pour le moment tu as peu de fonctionnalités mais si tu arrives a mettons 100 fonctions différentes et que la comparaison prend ne serait ce que 10ms (j'espere que c'est moins sur l'arduino ), tu auras un décalage d'une seconde entre effectuer la 1ere ou la derniere commande.

En gros façon, si tu veux réduire la latence, il faut faire le strict minimum en utilisant le plus de fonctions très simples voir directement des décalages, pointeurs de fonctions etc pour gagner en temps de traitement.

Bon courage pour la suite

Salut je pense qu'il parle un moteur qui a un axe (le même) des deux côtés genre: 

http://www.hobbyking.com/hobbyking/store/__23769__2725_Brushless_Outrunner_Motor_1600kv.html

Pour faire un robot pendulaire c'est vraiment pas terrible puisque dans ce cas tu ne pourras pas:

1. faire tourner ton robot : le robot avancera ou reculera tout droit (aux glissements prêts niveau roues)
2. la stabilisation se ferra donc sur un seul axe, il est surement préférable de gérer les deux roues différemment (ne serait si le sol n'est pas parfaitement plan)

En théorie ça doit pouvoir fonctionner avec un seul moteur dans la pratique j'ai des gros doutes sur la réussite.

De plus en partant sur un modèle à deux moteurs, tu peux t'inspirer (plus ou moins) de tous les "segway" homemade qui sont dispos partout sur le net.

Salut,

Je connais pas spécialement roborealm mais un recherche google rapide me donne cette page:

http://www.roborealm.com/help/Face_Detection.php

Par contre l'algo de Viola et Jones permet de faire de la reconnaissance d'objets, mais sur un objet tronqué je doute que tu arrives à des résultats cohérents.

Le plus dur sera dans tous les cas de créer ton classifieur (quoi de lui "expliquer" ce qu'il doit trouver dans une image), pour la reconnaissance de visage, openCV intègre déjà le classifieur de mémoire.

Si tu veux faire ton classifieur, il te faudra trouver des milliers d'images qui ne possèdent que ce que tu veux reconnaître, des milliers sans , et encore des milliers qui ont ce que tu veux reconnaître mais en situation réelle (avec un fond non homogène).

Et une personne dans toutes ses positions, tronquée ou autre me semble un objet un peu trop complexe pour être détectée d'un coup (peut être faire des détections de "morceaux" de personnes et de vérifier si les différents morceaux sont contigu)

Si tu veux comprendre un peu mieux l'algo va voir:

http://www.firediy.fr/article-18.html qui possède un lien pour expliquer comment faire son classifieur (je ne l'ai pas lu)

Bonjour à tous!
Ca fait quelques jours que je me pose la question : Est il possible de faire un suivi de personne avec une vue en 2d?
J'ai actuellement une webcam classique (2d) dans la tête du robot, comme j'aimerai qu'il interagit avec des personnes je me demande si je vais la garder..
J'ai regardé plein de video sur Youtube, notamment avec des kinects. Ca semble très efficaces!
Alors y'a t'il des algorithmes efficaces avec la 2d pour arriver a ces résultats?

Salut,

Oui cela est tout à fait est possible avec un simple flux video.

Un algo "connu" pour la détection de visage (ou d'objet d'ailleurs) est celui de Viola et Jones (http://fr.wikipedia.org/wiki/M%C3%A9thode_de_Viola_et_Jones).

Si tu ne veux pas t'embêter avec le traitement d'image (ou que tu ne veux pas un algorithme vraiment très particulier), le plus simple reste d'utiliser openCV qui possède tout ce qu'il faut ou presque pour faire du traitement d'image.

Après suivant ton processeur, tu ne pourras pe pas utiliser openCV directement, mais comme cette lib est open source, tu peux regarder comment c'est implémenté.

Un exemple de détection basique de visage avec openCV : 

http://studio-horatio.fr/2012/03/16/tuto-opencv-facetracking/

(après je connais pas cet exemple la, mais sur google, en cherchant openCV visage detection par exemple tu auras pleins d'exemples)

Salut

Pour ta première question rien de compliqué tout est expliqué en détails dans ta datasheet.

En gros si tu veux pas t'embeter regarde

1. §7.1 (réveil/initialisation du module)
2. §7.3 (prise d'une image)

Tu as le set complet de commandes que tu vas devoir envoyer sur l'UART, les valeur entre () dans la datashette sont les valuers hexadécimale que tu doit envoyer, ta raspberry est a gauche sur les logigrammes (en blanc), la caméra à droite (en gris).

Pour l'affichage d'une image ca dépend si tu veux le faire toi ou pas, le plus simple pour commencer c'est d'enregistrer ton image reçue en question 1 quelque part sur ton raspberry puis d'utiliser le petit sof FBI (voir http://www.framboise314.fr/premiere-image-de-la-camera/pour l'installation et l'utilisation), ça te permettra de valider que tu reçois bien des images correctes etc.

Pour commencer je te conseil aussi d'éviter de te complexifier la tache avec le multiplexeur etc., commence simple, une caméra, un uart et quand ca fonctionne comme tu veux tu enchaines

Salut,

C'est effectivement un problème classique que l'on rencontre quand on utilise des valeurs signées et non signées en même temps et sans en tenir compte...

Par contre techniquement parlant il n'y a pas de "dépassement" ou autre d'un char, je m'explique!

Pour commencer même si on parle de valeur signée ou non, en vrai en informatique la notion n'existe pas (c'est juste une abstraction rajoutée), les registres ou autres ont juste des valeurs binaires composées donc d'un ensemble de 1 ou 0 mais il n'y a pas de notion de négatif ou positif.

bref pour reprendre l'exemple,

la valeur de i est un unsigned int, donc une valeur codée sur 2 ou 4 octets (ça dépend de l'arduino utilisé), prenons 2 octets pour l'exemple.

Notre i va varier de 00000000 00000000b à 00000000 11111111b

cette variable est mise dans un char codé sur un octet ce qui nous fait qu'en fait on tronque l'int de son octet de poids fort pour garder que le deuxième (poids faible)

Ce tableau aura donc en

première "case"     (00000000) 00000000b (partie tronquée entre parenthèses)

deuxième "case"    (00000000) 00000001b

...

127eme case         (00000000) 01111111b

128eme case         (00000000) 10000000b

129eme case         (00000000) 10000001b

...

255eme case         (00000000) 11111110b

256eme case         (00000000) 11111111b

On voit donc que aucun dépassement n'est arrivé (mis a par le passage int en char mais l'octet de poids fort est toujours à 0), en revanche puisque tu as déclaré un "char" qui est officiellement signé, ta fonction de print va essayer de réaliser l'abstraction du signe qui est basiquement le premier bit d'une valeur signée est le  signe, si c'est un 0 c'est positif si c'est un 1 c'est négatif.

C'est pourquoi l'affiche jusque la 127eme case reste "normale", le char commence par 0, donc on l'affiche comme du positif

A partir de la 128eme case, le premier bit passant à 1, il est considéré négatif, et donc la fonction print va envoyer la représentation du contenu de cette case en négatif

Toussa pour dire que ce comportement n'est pas du tout inattendu et n'est juste que la représentation finale qui est réalisée en utilisant un mauvaise "encodage" (comme si tu veux afficher un texte encodé en Unicode en le décodant avec du ISO 8859, le texte ne sera pas lisible directement, même si le contenu de ton fichier n'est en fait pas changé)

Pour le code en lui même, il est plutôt conseiller d'utiliser le type byte pour des valeurs non signées sur un octet (à la place de unsigned char) même si le résultat sera le même. De même stocker une valeur codée sur plus d'octets que celle de stockage (ici mettre un int dans un byte) amène très souvent à des gros problèmes (pas le cas ici) puisque qu'en tronquant les valeurs, tu vas réduire la plage de valeur possibles et avoir des "bouclages".

Cordialement

Salut,

Tu as tout d'expliqué plutôt clairement ici pour transformer un servomoteur en moteur CC:

http://www.robot-maker.com/tutorials/article/47-modification-dun-servomoteur-en-moteur-a-rotation-continue/

Salut,

Il va falloir jouer avec les interruptions matérielles si tu veux que ce soit (presque) instantané.

En gros une interruption matérielle comme son nom l'indique va interrompre immédiatement le code en cours sur un événement quelconque:

• un timer
• une entrée qui change
• ...

et surtout va alors exécuter le code de ton interruption (ISR en anglais pour Interrupt Service Routine), en gros ça t'exécute une fonction (sans paramètre ni retour) que tu choisis. 

Dans ton cas il faut une interruption sur une entrée.

Sur le nano tu as deux entrées qui peuvent être utilisées pour les interruptions D2 et D3 (il me semble).

Après il faut utiliser la fonction attachIntterupt() (http://arduino.cc/en/Reference/AttachInterrupt).

Ca permettra de sépécifer le type d'interruption sur quelle entrée et la fonction à exécuter.

Un exemple un peu plus complet que sur le site arduino : http://www.laboelectronique.be/ardinterrupt.html