1 Dernière modification par AstonDB8 (08-01-2012 09:52)

Sujet : Pilotage caméra

Bonjoiur

Il fallait bien que cela arrive. J'ai donc repris le travail après une longue maladie.
Cette longue période m'a permis d'apprendre pas mal de choses concernant les µC et notamment Arduino.
Mais aujourd'hui, j'aimerais lier l'utile à l'agréable en utilisant une Arduino dans le cadre de mon travail.

Un des 1ers projets qui m'est confié est de créer une télécommande pour une caméra Panasonic.
Pour le moment nous utilisions une interface Web pour la piloter de n'importe ou.
On me propose de trouver une solution pour l'utiliser différemment. J'ai donc pensé à faire une boite avec Joystick pour la commander en local.
Bien sûr la solution la plus simple serait de conserver le même mode de pilotage (donc avec la même interface Web mais sur un V-Lan local). Oui, mais voila il est préférable d'avoir une commande Wardware et ne pas utiliser un PC dédié juste pour piloter une Caméra alors qu'un simple petit boitier relié en RS suffirait largement.
J'ai donc pensé à utiliser une carte Arduino pour gérer quelques boutons poussoir et un joystick 3axes.

Cette caméra (ainsi que sa tourelle) se pilote très simplement avec de simples commandes sur un port RS232
Voilà le modèle de la caméra ainsi que son protocole de communication.
http://dl.dropbox.com/u/4673542/CONVERTIBLE_RS232C.pdf
Et voilà les commandes que je dois implémenter dans la télécommande
http://dl.dropbox.com/u/4673542/Command … yncast.xls

Je dois bien sûr dans un 1er temps convertir le Port RS232 de la caméra en un UART TTL pour l'Arduino
Pour cela, je vais soit utiliser un montage à base d'un MAX232 ou utiliser une carte toute faite de ce genre
http://www.virtualvillage.fr/convertiss … 2-008.html
Qui coute à peine plus cher que le MAX232

Ensuite, je vais devoir écrire sur le Port UART les commandes de la caméra
Mais c'est là où j'aurais besoin d'aide.
Je n'ai bien sûr pas de librairie dédiée pour cette caméra.
Je vais donc devoir faire un write de chaque commande derrière chaque bouton ce qui peut être fastidieux.

Pouvez-vous me dire quelle serait la méthode la plus simple ?
Voir même me donner un exemple ?

Merci

Cdlt
Yves

2

Re : Pilotage caméra

Salut Yves,

Il fallait bien que cela arrive. J'ai donc repris le travail après une longue maladie.

C'est quand même positif, car cela semblerait dire que ça va mieux sur le plan santé.

Je vais donc devoir faire un write de chaque commande derrière chaque bouton ce qui peut être fastidieux.

Pouvez-vous me dire quelle serait la méthode la plus simple ?

Il y a deux options pour ne pas se taper tout le code à la main :

1/ générer le code source automatiquement (ou une bonne partie en tout cas) à partir du tableau Excel avec un script écrit en VB sous Excel par exemple, ou en autre chose qui lirait en entrée un export CSV par exemple du tableau). Il y aurait une fonction C par commande à gérer

2/ plus économique en taille de code : définir un format de stockage des séquences dans un structure statique  plus ou moins complexe (tableau,...) qui serait produite par la même méthode que pour l'option (1) et écrire une fonction générique qui se serve de ces données pour émettre les commandes sur la liaison série.

Ces deux approches devraient permettre de gérer facilement toute la série des commandes simples. Il ne resterait plus que les quelques séquences composées (à partir de la ligne 120) à implémenter à la main. Encore qu'on pourrait imaginer que la fonction générique soit capable de gérer aussi de telles commandes, mais est-ce que ça en vaut la peine ?

Cordialement

Eric

3

Re : Pilotage caméra

Bonjour et merci

En fait je ne sais pas si je saurais faire ça.
Ce que je comptais faire:
Soit créer un tableau comportant les commandes
Soit gérer des fonctions (1 par commande)
Par exemple pour le pan_left dont la commande est "#P43<CR>"



void pan_left_1(void) {
Serial.print("#P43\n");
}

A contrôler si le retour chariot <CR> peut être remplacé par "\n"
Mais cette solution est assez longue à écrire.
Je cherchais donc une solution plus élégante et plus rapide.
Mais depuis que je cherche, j'aurais déjà écrit mes 120 fonctions wink

Question
Un fichier csv doit être localisé sur un support accessible par le µC donc nécessite un support du genre carte SD ?

Autre chose, une fonction générique se référant à une liste de constantes (je pense que c'est ce que tu proposes en 2) pourrait faire la farce ?

Donc pour résumer :
1/ un tableau contiendrait les commandes
2/ une liste de constante contiendrait les commandes
Une fonction générique se référerait soit au tableau, soit à la liste de constante.

Penses-tu que nous nous soyons bien compris ?
Vois-tu une autre solution ?
Si nous ne nous sommes pas compris, peux-tu me montrer un exemple ?

Merci encore

Cdlt
Yves

4

Re : Pilotage caméra

Salut Yves,

Soit créer un tableau comportant les commandes

C'est la solution (2) dans mon suggestion

Soit gérer des fonctions (1 par commande)

C'est la solution (1)

Dans le cas de l'option (1) ma proposition pour éviter de tout écrire à la main consiste à écrire un outil qui va générer le code C du programme. De cette manière s'il y a une erreur de "traduction", il est plus facile de recommencer la génération du source que de corriger à la main les n fonctions.

Un fichier csv doit être localisé sur un support accessible par le µC donc nécessite un support du genre carte SD ?

Pas du tout, et ce serait un énorme gaspillage de place, sans compter que le traitement de ce genre de format est une charge importante à l'échelle d'un µC. L'option (2), et à laquelle tu fais référence je suppose dans ta question, consiste à générer une structure de donnée la plus directe à utiliser, par exemple un tableau contenant les chaines de caractères correspondant aux commandes. L'index de ce tableau peut être symbolisé par une constante comme tu en fais la suggestion, elle-même générée automatiquement. Ainsi la fonction d'envoi générique se résume à quelque chose du genre :

static char * all_commands[] {
  "P43",
  "P45",
  ...
};

typedef enum {
  Pan_Left_1,
  Pan_Left_2,
  ...
} COMMAND ;

void send_cmde(COMMAND cmde) {
  Serial.print('#');
  Serial.print(all_commands[cmde]) ;
  Serial.print('\r');
}

utilisation :

send_cmde(Pan_Left_2);

ou plus vraisemblablement :

send_cmde(which_cmde); // avec which_cmde de type COMMAND et initialisé par le code qui détecte le bouton appuyé

Ca c'est le principe de base. Pour être efficace en taille au niveau du tableau, les parties invariantes (comme le '#' et le <CR>) peuvent être ajoutées par la fonction d'envoi.

J'ai utilisé un enum au profit d'une série de #define pour tout simplement s'éviter de gérer la numérotation séquentielle. C'est strictement équivalent à :

#define Pan_Left_1 0
#define Pan_Left_2 1
...

A contrôler si le retour chariot <CR> peut être remplacé par "\n"

Absolument pas : '\n' vaut 0x0A alors que '\r' vaut 0x0D.

5

Re : Pilotage caméra

Je viens de m'amuser à écrire le générateur de code, qui utilise l'export de ton tableau au format CSV, avec la tabulation comme séparateur et pas de quotes autour des chaines.

C'est basé sur l'excellent outil "awk", dont l'efficacité est démontrée (s'il le fallait encore) par la taille on ne peut plus modeste des scripts mis en oeuvre.

Un premier script awk génère la définition de l'énuméré :

#!/usr/bin/awk -f 

BEGIN {
    FS = "\t";
    print "typedef enum {";
}
    
NR >= 3 && NR <= 119 && $1 != "" {
    sub(" ", "_", $1);
    sub("+", "plus", $1);
    sub("-", "minus", $1);
    printf("    %s,\n",$1);
}

END {
    print "    last_cmd\n} COMMAND ;";
}

Un deuxième produit la table des commandes :

#!/usr/bin/awk -f 

BEGIN {
    FS = "\t";
    print "static char *all_commands[] = {";
}
    
NR >= 3 && NR <= 119 && $2 != "" {
    sub("<CR>", "\\r", $2);
    sub("<STX>", "\\002", $2);
    sub("<ETX>", "\\003", $2);
    printf("    \"%s\",\n",$2);
}

END {
    print "    0\n} ;";
}

Les commandes de mise en oeuvre sont :

$ ./gen-typedef.awk webdyncast.csv > webdyncast.c 
$ ./gen-command-table.awk webdyncast.csv >> webdyncast.c

Ce qui donne le souce C suivant:

typedef enum {
    Pan_Left_1,
    Pan_Left_2,
    Pan_Left_3,
    Pan_Left_4,
    Pan_Left_5,
    Pan_Stop,
    Pan_Right_1,
    Pan_Right_2,
    Pan_Right_3,
    Pan_Right_4,
    Pan_Right_5,
    Tilt_Left_1,
    Tilt_Left_2,
    Tilt_Left_3,
    Tilt_Left_4,
    Tilt_Left_5,
    Tilt_Right_1,
    Tilt_Right_2,
    Tilt_Right_3,
    Tilt_Right_4,
    Tilt_Right_5,
    Tilt_Stop,
    Zoom_Wide_1,
    Zoom_Wide_2,
    Zoom_Wide_3,
    Zoom_Wide_4,
    Zoom_Wide_5,
    Zoom_Stop,
    Zoom_Tele_1,
    Zoom_Tele_2,
    Zoom_Tele_3,
    Zoom_Tele_4,
    Zoom_Tele_5,
    Focus_Near_1,
    Focus_Near_2,
    Focus_Near_3,
    Focus_Near_4,
    Focus_Near_5,
    Focus_Stop,
    Focus_Far_1,
    Focus_Far_2,
    Focus_Far_3,
    Focus_Far_4,
    Focus_Far_5,
    Iris_Auto,
    Iris_Manual,
    ON,
    OFF,
    PreSetMem_2,
    PreSetMem_3,
    PreSetMem_4,
    PreSetMem_5,
    PreSetMem_6,
    PreSetMem_7,
    PreSetMem_8,
    Mem_2,
    Mem_3,
    Mem_4,
    Mem_5,
    Mem_6,
    Mem_7,
    Mem_8,
    Menu_On,
    Menu_Off,
    Page_Up,
    Page_Down,
    Yes_plus,
    No_minus,
    Tilt_Left_1,
    Tilt_Stop,
    Tilt_Left_2,
    AWC0,
    AWC1,
    PreSetMem_1,
    PreSetMem_9,
    PreSetMem_10,
    PreSetMem_11,
    PreSetMem_12,
    Mem_1,
    Mem_9,
    Mem_10,
    Mem_11,
    Mem_12,
    ABB,
    MireON,
    MireOFF,
    Tilttest,
    Iris_01,
    Iris_05,
    Iris_10,
    Iris_15,
    Iris_20,
    Iris_25,
    Iris_30,
    Iris_35,
    Iris_40,
    Iris_45,
    Iris_50,
    Iris_55,
    Iris_60,
    Iris_65,
    Iris_70,
    Iris_75,
    Iris_80,
    Iris_85,
    Iris_90,
    Iris_95,
    Iris_99,
    Butee_Bas,
    Butee_Haut,
    Butee_Droite,
    Butee_Gauche,
    AWC2,
    BalanceBlanc,
    TallyOn,
    TallyOff,
    last_cmd
} COMMAND ;
static char *all_commands[] = {
    "#P43\r",
    "#P45\r",
    "#P40\r",
    "#P30\r",
    "#P01\r",
    "#P50\r",
    "#P60\r",
    "#P60\r",
    "#P65\r",
    "#P70\r",
    "#P99\r",
    "#T45\r",
    "#T38\r",
    "#T35\r",
    "#T30\r",
    "#T01\r",
    "#T53\r",
    "#T60\r",
    "#T65\r",
    "#T70\r",
    "#T99\r",
    "#T50\r",
    "#Z49\r",
    "#Z48\r",
    "#Z45\r",
    "#Z30\r",
    "#Z01\r",
    "#Z50\r",
    "#Z51\r",
    "#Z53\r",
    "#Z56\r",
    "#Z70\r",
    "#Z99\r",
    "#F49\r",
    "#F48\r",
    "#F45\r",
    "#F35\r",
    "#F01\r",
    "#F50\r",
    "#F51\r",
    "#F53\r",
    "#F56\r",
    "#F70\r",
    "#F99\r",
    "#D31\r",
    "#D30\r",
    "#O1\r",
    "#O0\r",
    "#M02\r",
    "#M03\r",
    "#M04\r",
    "#M05\r",
    "#M06\r",
    "#M07\r",
    "#M08\r",
    "#R02\r",
    "#R03\r",
    "#R04\r",
    "#R05\r",
    "#R06\r",
    "#R07\r",
    "#R08\r",
    "\002DUS:1\003",
    "\002DUS:0\003",
    "\002DPG\003",
    "\002DIT\003",
    "\002DUP\003",
    "\002DDW\003",
    "#T45\r",
    "#T50\r",
    "#T38\r",
    "\002OAW:0\003",
    "\002OAW:1\003",
    "#M01\r",
    "#M09\r",
    "#M10\r",
    "#M11\r",
    "#M12\r",
    "#R01\r",
    "#R09\r",
    "#R10\r",
    "#R11\r",
    "#R12\r",
    "\002OAS\003",
    "\002DCB:1\003",
    "\002DCB:0\003",
    "#T45\r",
    "#I20\r",
    "#I23\r",
    "#I26\r",
    "#I29\r",
    "#I32\r",
    "#I35\r",
    "#I38\r",
    "#I41\r",
    "#I44\r",
    "#I47\r",
    "#I50\r",
    "#I53\r",
    "#I56\r",
    "#I59\r",
    "#I62\r",
    "#I65\r",
    "#I68\r",
    "#I71\r",
    "#I74\r",
    "#I77\r",
    "#I80\r",
    "#L1\r",
    "#L2\r",
    "#L3\r",
    "#L4\r",
    "\002OAW:2\003",
    "\002OWS\003",
    "#D41\r",
    "#D40\r",
    0
} ;

Ce source ne compile pas tel quel car il y a des répétitions dans le tableau, qui se traduisent donc par des identificateurs déclarés deux fois hmm 

$ gcc webdyncast.c
webdyncast.c:70: error: redeclaration of enumerator ‘Tilt_Left_1’
webdyncast.c:13: note: previous definition of ‘Tilt_Left_1’ was here
webdyncast.c:71: error: redeclaration of enumerator ‘Tilt_Stop’
webdyncast.c:23: note: previous definition of ‘Tilt_Stop’ was here
webdyncast.c:72: error: redeclaration of enumerator ‘Tilt_Left_2’
webdyncast.c:14: note: previous definition of ‘Tilt_Left_2’ was here

En prime tu as donc un outil de vérification de ta table Excel wink Ceci étant, à défaut de corriger le tableau Excel, il est facile de corriger à la main le source C, sur la base des messages du compilateur.

Tu noteras que mes scripts gèrent :
- la substitution des espaces dans les identificateurs par des "_"
- la substitution de caractères qui ne sont pas autorisés dans des identificateurs C, comme "+" ou "-",
- la conversion des symboles STX et ETX en leurs équivalents binaires.

On ne peut finalement pas supprimer les '#' et '\r' comme suggéré dans mon message précédent, car certaines commandes utilisent d'autres préfixes et suffixes (<STX> et <ETX>).

Je n'ai pas géré les commandes des autres sites, mais le principe est identique, en sélectionnant  le champ de l'enregistrement correspondant à la colonne du tableau.

Have fun wink

6

Re : Pilotage caméra

Houla...
Eric...
Super...

Je ne suis pas certain d'avoir vraiment compris le principe ais je vais m'y pencher
Effectivement, c'est bien plus court que ce que j'imaginais...

Pour les doublons pas d'inquiétude. Dans le code de l'application Web, nous utilisions plusieurs fois les mêmes commandes.
Ce qui permettait de nommer des boutons comme nous le souhaitions en fonction du contexte (même si derrière ce bouton, il y avait la même commande). Je vais donc faire un tri et sans doute simplifier, car cette télécommande et destinée à être utilisée par des journalistes (pas très techniques donc) je vais donc tacher d'utiliser des fonctions automatiques (Balance des balances et des noirs, iris, sans doute focus)
J'aimerais arriver à garder les positions et les mémoires de position. le reste pourrait n'appaire que dans un menu caché accessible avec un PC (donc pas géré par le µC)

Je vais donc voir comment utiliser ça et vous tiendrais au courant bien sûr.
En tout cas, c'est vraiment super d'avoir fait ce travail.
Merci Eric

Cdlt
Yves

7

Re : Pilotage caméra

AstonDB8 a écrit:

Je ne suis pas certain d'avoir vraiment compris le principe ais je vais m'y pencher

Au cas où tu ne connaisse pas awk, il s'agit d'un outil issu du monde Unix, mais également disponible sous Windows et al. Il est fait pour traiter séquentiellement le contenu d'un fichier, texte à priori. Il gère de lui-même l'itération sur les enregistrements du fichier (aka les lignes) ainsi que la séparation des champs de chaque enregistrement. Il dispose également d'un langage qui permet :
- de définir des critères de sélection de certaines lignes
- d'y appliquer un traitement spécifique

On peut fournir ces instructions directement lors de l'invocation de awk si elles restent simples, ou bien les regrouper dans un script comme ici.

La structure des scripts est très simple. C'est une succession de blocs constitués par :
- une clause de sélection de ligne (éventuellement vide)
- une suite d'instructions, encadrées par des accolades.

Il existe des clauses de sélection un peu spéciales telles que BEGIN et END qui permettent respectivement de définir le traitement à exécuter avant de commencer à itérer sur le contenu du fichier et END qui permet la même chose mais avant de quitter le script.

Analysons plus en détail le premier des deux scripts, dont le rôle est de générer le code source qui défini le type énuméré de toutes les commandes.

contenu du bloc BEGIN

FS = "\" ;

définit le séparateur de champ (FS = Field Separator) comme étant la tabulation (par défaut c'est l'espace)

print "typedef enum {";

produit le début du code C qui définit l'énuméré

bloc de traitement des enregistrements

NR >= 3 && NR <= 119 && $1 != ""

sélectionne les lignes telles que :
- le numéro de ligne est >= 3 (NR = Number of Record) pour ne pas traiter l'entête du tableau Excel
- et <= 119 pour s'arrêter à la fin de la liste des commandes "simples"
- et le champ qui contient  l'identificateur de commande (le premier champ de la ligne, d'où "$1") n'est pas vide, pour ne pas traiter les lignes qui ne sont pas des commandes dans le tableau)

 
sub(" ", "_", $1);
sub("+", "plus", $1);
sub("-", "minus", $1);

remplace dans le contenu du champ les caractères invalides dans le cadre d'un identificateur C, soit l'espace et les signes '+' et '-' (l'instruction sub modifie directement le contenu de la variable passée en dernier paramètre)

printf("    %s,\n",$1);

émet l'instruction C correspondante

bloc END

print "    last_cmd\n} COMMAND ;";

émet l'instruction de fin de déclaration de l'énuméré.

Pourquoi j'ajoute un identificateur (last_cmd) ne correspondant à aucune commande ? Tout simplement pour me simplifier la vie au niveau de la gestion de la virgule qui sépare les différents éléments de l'énuméré. Sans ce trick, il aurait fallu que je détecte si j'étais sur le dernier identificateur ou non dans le bloc précédent, et c'est moins simple que ça en a l'air car on n'a en réalité aucun moyen de savoir si l'instruction C qu'on va produire est le dernier item ou non à ce point-là.

Voilà. C'est tout bête.

Ce script awk ne contient ici qu'un seul bloc de traitement d'enregistrement, mais il peut y en avoir autant qu'on veut, pour faire des traitements spécifiques selon le contenu de la ligne d'entrée, ces blocs peuvent se cumuler, s'exclure,.... C'est très puissant, et finalement pas très difficile à apprivoiser.

Je te laisse le soin de décortiquer le deuxième script à titre d'exercice wink

8

Re : Pilotage caméra

Donc si je comprends bien ton code

Une fois que j'ai réglé les problèmes de doublons, je n'ai plus qu'à appeler les commandes de cette façon ?

Serial.print(all_commands[Pan_Left_1]);

Je n'ai pas encore fait de" test, car je n'ai pas encore reçu ma commande pour un MAX232 sans lequel je ne peux pas communiquer en RS232 de"puis une Arduino

Cdlt
Yves

9

Re : Pilotage caméra

Une fois que j'ai réglé les problèmes de doublons, je n'ai plus qu'à appeler les commandes de cette façon ?
Serial.print(all_commands[Pan_Left_1]);

Yes Sir smile

10

Re : Pilotage caméra

Bon aller Quand faut y aller faut y aller alors je me lance dans la fabrication du prototype.
Le (les) modèles de production seront donnés en fabrication à une câbleur pouvant nous faire un travail et une finition irréprochable (Circuit imprimé, boitier gravé etc...)

Le compte est fait
25 bouton poussoir
3 codeurs rotatif
25 LEDs
1 Écran LCD (16x3 ou 16x2)
Une liaison série RS232
1 alimentation secteur 9v
un module de régulation 5v

La solution du Joystick est pour le moment mise de coté (de toutes façons, il était question de prendre un joystick à µrupteurs et pas à potentiomètres)

Par contre, le nombre de pin nécessaire est énorme.
Je dois donc trouver une solution pour réduire le nombre de pins utiles tout en gardant les mêmes fonctionnalités.

Pour brancher 25 boutons poussoir, j'ai 3 solutions
1/ La plus folle et donc infaisable (Relier chaque poussoir à une Pin) 25 Pins juste pour les poussoirs. De la folie en somme.
2/ Faire un branchement en matrice (25 poussoirs soit une matrice de 5lignes X 5 Colonnes) pas mal 10 Pins pour 25 poussoirs. plus responsable déjà.
3/ Utiliser des résistances (par groupe de 5 poussoirs en utilisant 5 résistances (330, 620, 1K, 33K) et relier 5 poussoir à 1 pin analogique. Dont 5 Pins Analogiques.

Si j'élimine d’office la solution 1, les solutions 2 et 3 sont parfaitement viables. Mais à votre avis, quelle est la solution la plus fiable, et la plus rapide en traitement. ?
Y a t'il une véritable différence de fiabilité ou autre ? Car cette solution doit être fiable et sans aucune erreur.

Sinon, Idem pour les LEDs. Il existe plusieurs solutions.
1/ la matrice 25 LEDs donc une matrice de 5x5 la encore. donc 10 Pins (en connectant les 10 Pins directement aux lignes et aux colonnes de ma matrice)
2/ En utilisant un circuit spécialisé de gestion de matrice (MAX7219 ou MAX7221 par exemple) ces CI permettent de gérer jusqu'à 64 LEDs (8x8) piloté en SPI donc 3 pins pour gerer mes 25 LEDs.

http://datasheets.maxim-ic.com/en/ds/MA … AX7221.pdf

Donc même question, que pensez vous de chaque solution et y en t'il une plus fiable une l'autre ?


Aller encore une ou deux questions.
Je pensais que je devais mettre une résistance PullUp pour les Poussoirs. Mais en voir les schéma trouvés sur le Net, aucun d'entre eux ne comporte de résistance. ??? Plutôt étrange non ?

Idem pour le câblage de matrice de LEDs. Comment calculer la valeur de de la résistance d'adaptation de courant lorsqu’il est impossible de savoir combien de LEDs sauront allumées en même temps. (Je précise que les schémas de matrices ne comportent aucune résistance ce qui est bien sur impossible.
Par exemple
http://arduino.cc/en/Tutorial/RowColumnScanning

Aller, dernière question (juré wink  )
Les PullUp internes sont bien sur une bonne solution, mais combien de PullUp internes peut on déclarer dans le même projet ?
Il n'y a pas une résistance par Pin tout de m^me non ?

Merci
Cdlt
Yves

11

Re : Pilotage caméra

Tu peux multiplexer les I/O en utilisant les expandeurs de port I2C (PCF8574). Cf ici pour les détails : http://www.nxp.com/products/interface_a … F8574.html

Ils comportent 8 I/O chaque, et on peut leur assigner 8 adresses, soit 8x8 = 64 I/O. Si ça ne suffit pas il suffit de panacher et la référence PCF8574A qui travaille sur une autre plage d'adresses, et on a dont au total 128 I/O. Le tout en ne consommant que les deux I/O SCL et SDA de l'I2C côté MCU.

Eric

12 Dernière modification par AstonDB8 (16-01-2012 20:33)

Re : Pilotage caméra

Super
En plus à 2.50€ les 5 franchement, ca ne vaut pas la peine de se compliquer la vie...
http://www.rs-particuliers.com/WebCatal … 70687.aspx

Pour les adresses
http://www.ti.com/lit/ds/symlink/pcf8574a.pdf
Effectivement ça semble très simple à gérer et 8x8 soit 64 I/O suffit empalement pour ce projet.
Je n'ai pas encore vu comment configurer les adresses mais je vais lire attentivement le datasheet.
Je passe commande de deux lots de 5 modules. nous verrons bien.
40mA par port est parfait pour les poussoirs mais les Leds ?
A voir.
Merci en tout cas je ne connaissais pas et je sent que je vais rapidement être fan.

Pour info voila une 1ere base de travail
http://dl.dropbox.com/u/4673542/Visio-Matrice_1-1.pdf
http://dl.dropbox.com/u/4673542/T%C3%A9 … de-1-2.pdf
http://dl.dropbox.com/u/4673542/Visio-T … ma_1-2.pdf

Voila en tout cas ou j'en étais avant ton message. Mais le projet evolu de jour en jour puisque même le schéma d’implantation est faux aujourd'hui wink

Cdlt
Yves

13

Re : Pilotage caméra

La définition de l'adresse d'un PCF se fait en positionnant les états des lignes A0-A2 (d'où les 8 valeurs possibles) via leur connexion à VCC ou GND.

Concernant les LED, tu peux t'en sortir en utilisant des buffers (aka line driver) comme celui-ci par exemple : http://fr.farnell.com/allegro-microsyst … dp/1193495
Il contient 8 drivers, ce qui du coup match avec le PCF. De plus il intègre les diodes de roue libre permettant de piloter des relais sans devoir ajouter de composant supplémentaire.

Au fait, un point très important : les I/O ne fonctionnent pas comme celles d'un MCU. Elles sont capables de sinker 20mA, voire plus, mais pas de sourcer (ou très peu). C'est d'ailleurs indiqué dans le dernier tableau en page 4 du datasheet que tu références. Leur descriptif peut porter à confusion, car ils parlent d'I/O quasi bi-directionnelles.

14

Re : Pilotage caméra

Bonjour,

Désolé de vous avoir laissé sans nouvelle après l'aide que vous m'avez apportée sur ce montage, mais la vie professionnelle n'est pas non plus un long fleuve tranquille et il a falu gérer  les urgences (et des urgences, je n'en manque pas cet an ci)

Donc, bonne nouvelle ma télécommande fonctionne en

15

Re : Pilotage caméra

Bonjour,

Désolé de vous avoir laissé sans nouvelle après l'aide que vous m'avez apportée sur ce montage, mais la vie professionnelle n'est pas non plus un long fleuve tranquille et il a falu gérer  les urgences (et des urgences, je n'en manque pas cet an ci)

Donc, bonne nouvelle ma télécommande fonctionne en "théorie". ,Quand je dit en théorie, c'est que chaque fois que je presse un bouton, toutes les commandes liées à ce bouton s'affichent bien sur mon serial monitor et mon LCD affiche bien les messages qui renseignent sur l'action effectuée.

Bien 95% du travail est fait. Mais je bute sur les 5% restant.
Pas simple et je n'ai pas encore trouvé la solution.
La communication avec ma caméra est en RS422.
Je dois donc transformer de l'UART TTL en RS422
J'ai essayé de passer par un MAX232 puis un convertisseur 232/422 mais cela ne marche pas.
J'ai trouvé un composant qui devrait pouvoir faire cette conversion en une seule fois (UART TTL/RS422)
Il s'agit d'un AD7306 qui permet d'entrer soit :
En TTL
En 232
En 422

et de sortir soit
En TTL
En 232
En 422

Pour la sélection 232/422 il suffit de mettre la patte 15 en LOW ou HIGH
Ce composant se charge du reste il suffit de lui fournir du +5v et il fabrique les tensions et signaux de service dont il à besoin pour effectuer ces conversions

Voila le PDF
http://www.google.fr/url?sa=t&rct=j … mp;cad=rja

Bien je vais donc tester ce composant mais je ne comprend vraiment pas pourquoi cela ne marche pas avec un MAX232 connecté à un convertisseur 232/422 standard (genre petit boitier comportant deux Sub-D9) .

Si vous savez pourquoi je suis preneur ar l'AD7306 coute tout de même la bagatelle de 26€ (ce qui n'est pas excessif si ca marche mais hors de prix si cela ne fonctionne pas.

Cdlt
Yves

16

Re : Pilotage caméra

Quelle est la nature du convertisseur 232/422 que tu as essayé.

D'autre part, la liaison 422 avec la caméra est-elle du type multi-drop, ou bien est-ce juste une liaison point à point qui utilise une transmission différentielle pour être moins sensible au bruit (faut reconnaitre qu'un plateau TV est assez bien pourvu en générateur de perturbation, avec tous les systèmes HF et équipements de puissance à la ronde wink ?

17

Re : Pilotage caméra

Non effectivement, c'est juste un point à point (utilisé pour permettre une plus grande longueur de câble)
Car les équipement sont dans un nodal alors que les cam sur un plateau.
en plus cela passe par un maillage assez copieux et même si nous evitons de melanger les courants faibles au lignes de force, il y a toujours un moment ou cela se croise.

En fait je suis a la recherche d'un analyseur de protocole.
Il me permettra de bien voir ce qui transite par la RS.
Le composant dont j'ai mis le lien dans mon message précédent devrait (j’espère) régler le PB. Mais rien de moins sur...

Si tu veux te pencher sur le PB, (déjà à titre d'information) voila les docs et protocole.
Manuel de service
De la tourelle
http://dl.dropbox.com/u/4673542/AW_PH35 … manual.pdf
http://dl.dropbox.com/u/4673542/Service … -E600E.pdf
De la caméra
http://dl.dropbox.com/u/4673542/Service … -E600E.pdf
Instruction de la tourelle
http://dl.dropbox.com/u/4673542/AW-PH35 … ctions.pdf
Protocole
http://dl.dropbox.com/u/4673542/CONVERTIBLE_RS232C.pdf
http://dl.dropbox.com/u/4673542/Convert … _V2_33.pdf

Il manque l'optique mais il est pris en charge par les commandes de la caméra
C'est un Fujinon S20X6 4BMD-DSD 1:1.4 6.4 X 120.mm pour caméra 3CCD 1/2 pouce
http://www.expandore.biz/product_detail … mp;start=1

la particularité de cette optique est de ne pas avoir de commandes externe. Tout se faisan par RS422.

Cdlt
Yves

18

Re : Pilotage caméra

AstonDB8 a écrit:

Bien je vais donc tester ce composant mais je ne comprend vraiment pas pourquoi cela ne marche pas avec un MAX232 connecté à un convertisseur 232/422 standard (genre petit boitier comportant deux Sub-D9) .

Peut-être des pistes dans ce document : http://www.antona.com/trbsh6000.htm

19

Re : Pilotage caméra

Éric

Merci pour ce lien. Je regarderais lundi.
De toutes façons, la seule explication serait de devoir croiser RX et TX soit en coté µC soit coté Caméra.
Je suis en relation avec l’ingénieur produit Pana. Il serait bien surprenant qu'il ne me fournisse pas une solution opérationnelle.
Il est vrai qu'ils ne sont pas fan de solutions exotiques tel que ce montage (ils vendent une télécommande dédiée). Mais à 6K€ la télécommande même si je passe du temps à mettre ma solution au point le jeu en vaut la chandelle.

Par contre, je me demande si mon câblage est vraiment bon. je m'explique
J'utilise uniquement de Pin en sortie µC (Rx Et Tx) un +5v et un GND et Trois fils coté Sub D9 (Rx Tx Gnd)
Je n'ai pas a me trompé puisque j'ai un module tout fait.
Ce module utilise un MAX3222E
https://docs.google.com/viewer?pid=expl … P3232E.pdf
Il n'y a (semble t(il) aucune différence avec un MAX232 sauf que le 3222E ne comporte qu'une seule liaison série (Donc 1 Rx et 1 Tx) Alors que le MAX232 en comporte 2.

Il me reste encore une explication (peux probable) mon module est cramé wink
Je vais donc faire mon propre montage (qui de toute façon fera plus propre dans le montage définitif et évitera de me retrouver avec plusieurs cartes interconnecté.

https://docs.google.com/viewer?pid=expl … 32_sch.pdf

Question, 104 pour une capa nous donne bien 100000pF ? Soit 100nF soit 0,1µF
Mais certains schémas nous montre des capas polarisées et d'autres non polarisées.
Et comme les valeurs de 01µF polarisées sont introuvables sur le marché utiliser des non polarisées m'arrangerait bien.

Bon attendons lundi pour j’espère avancer sur ce dossier.

Cdlt
Yves

20

Re : Pilotage caméra

Salut Yves,

J'utilise uniquement de Pin en sortie µC (Rx Et Tx) un +5v et un GND et Trois fils coté Sub D9 (Rx Tx Gnd)

C'est correct

Il n'y a (semble t(il) aucune différence avec un MAX232 sauf que le 3222E ne comporte qu'une seule liaison série (Donc 1 Rx et 1 Tx) Alors que le MAX232 en comporte 2

Je n'ai plus en tête les différentes variantes du MAX mais je crois me souvenir qu'il y a des versions TTL 3V et TTL 5V. Vérifie éventuellement ce point.

Il me reste encore une explication (peux probable) mon module est cramé

As-tu essayé des tests en loopback progressif ? C'est à dire en rebouclant Rx et Tx à la sortie du ?P, puis progressivement étape par étape jusqu'au bout de la liaison (c'est à dire au niveau de la caméra).

Question, 104 pour une capa nous donne bien 100000pF ? Soit 100nF soit 0,1µF

104 c'est bien 100nF (la capa magique qui guérit tous les problèmes zarbis smile) Contrairement aux résistances où la mantisse est un réel compris entre 0 et 10 (exclu), le deuxième anneau étant donc une décimale, la mantisse des capas est un entier à plusieurs chiffres. Ici, ça fait donc 10 x 10^4, soit 10^5 pF, soit 100 nF.

Et comme les valeurs de 01µF polarisées sont introuvables sur le marché utiliser des non polarisées m'arrangerait bien.

Ca existe en capa au tantale par exemple : http://radiospares-fr.rs-online.com/web … e/5374025/

Bonne continuation

Eric

21 Dernière modification par AstonDB8 (29-01-2012 13:33)

Re : Pilotage caméra

Effectivement Eric

je ne savais pas comment cela s'appelait mais je connaissais ce test, je parle bien sur du Loop Back.
Et non, je n'ai pas fais ce test élémentaire..... wink
Bon je sais ce qu'il le reste a faire demain en 1ere heure wink

Shunter RX et TX en sortie de µC
Si le test fonctionne je mets mon MAX232 et boucle a nouveau RX et TX en sortie de module
Si le test fonctionne Je mets mon convertisseur 232 / 422 et shunt a nouveau Rx et TX
Et si le test fonctionne, c'est que j'ai soit un croisement a faire coté cam soit que la Cam ne fonctionne pas.
Et dans ce dernier cas, l'ingénieur Pana pourra m'aider.
Pour le moment, il me renvois vers mon câblage. Ce test est donc un bon moyen soit de savoir à quel endroit de ma chaine cela ne passe pas, soit de certifier à l’ingénieur Pana que le probleme est bien le sien wink

Merci encore Eric
Je te tiens au courant bien sur
Et des que ça marche, je vous met une vidéo (voir même un schéma (bien que ce montage sera tellement spécifique que peu de monde pourront le réutiliser) Enfin au moins pour la partie théorie.

Cdlt
Yves

PS;
Pour Julien
As tu eu le temps de passer a la poste ? wink

22

Re : Pilotage caméra

Bonjour

Les choses avancent. Pas suffisament à mon goût mais bon.

J'arrive enfin à communiquer avec la caméra (convertisseur USB / RS232 puis 232 / 422)
Le proble est que cette communication est établie grâce à un petit programme de test donné par Panasonic.
En gardant la même liaison impossible de communiquer en HyperTerminal.
Pourtant (confirmé par Le constructeur, mes comma
Des sont bonnes.

D'où une autre question. Pourquoi un soft connecté e
RS accepte de cmuniquer en point à point alors qu'un HyperTerminal ne le ferait pas.
Le test du Loop Back fonctionne. Cette même liaison doublée accepté de communiquer avec un autre PP en croisant le 422. ?

Y a t'il une ci
Figuration spéciale pour mon HyperTerminal lorsque j'utilise des commandes Hexa ?
Préfère t'il l'ASCII ou le Déc. ?

Bon je sais cela fzit plus d'une question. Mais ça comme
Ce a me miner.
Je n'ai jamais autant ramer pour dialoguer avec une Cam. Et pourtant j'en ai testé des dizaines wink


PS:
J'espère que Julien va vite se remettre de sa chute.
Il est donc impossible pour lui de passer à la poste wink
Mais peut être prendra t'il le temps de m'écrire un petit message.

Cdlt
Yves

23

Re : Pilotage caméra

Question bête : les commandes sont-elles envoyé en ASCII ? As-tu pu voir ce que le programme Pana envoie réellement ?

Je suppose par ailleurs que tu as configuré HT avec les mêmes paramètres de taille, parité, stop-bits,... que ceux utilisés par le soft Pana.

Une autre idée, mais je peux me tromper car je ne suis pas un spécialiste du 422 : il me semble que le RS422 est multi-drop à la base, et donc fait pour gérer plusieurs périphériques sur la même liaison physique. Si c'est bien le cas, il faudrait voir du côté du mécanisme d'adressage ou équivalent.

Bon courage

Eric

24 Dernière modification par AstonDB8 (03-02-2012 07:18)

Re : Pilotage caméra

Bon ça avance.

Jarrive à communiquer avec la camera depuis l'HyperTerminal.
C'était un problème de syntaxe.
Ma commande etait :
#O1<CR>
Pour allumer la cam ou
#O0<CR>
Pour l'éteindre par exemple.
Mais la bonne commende en HyperTerminal est
#O1
#O0
Et le retour chariot est envoyé par "Enter"
Ou il faut enregistrer un fichier txt contenant la commande et faire un retour à la ligne à la fin de la commande avant de registrer le fichier. Donc le retour chariot est un caractère ASCII non visible mais lu par hyperTerminal et interprété comme <CR>.

Donc la ça marche bien.   Ce qui marche bien egalement est de lancer des commandes depuis la carte Arduino par un "print" vers l'HyperTerminal.
La c'est une simple copie des caractères envoyés. Les carracteres envoyés sont comiés dans la fenêtre d'HyperTerminal comme ils le seraient dans la fenêtre du Serial Monitor. Donc interressant pour du debogage. Car celà permet de s'assurer de la commande envoyée par le tuer directe.  Mais les commande ne sont pas interprétées. Juste affichées et tout passe bien.

Par contre, (encore) impossible d'envoyer des commandes depuis Arduino vers la cam.
En fait je ne sais pas si les commandes sont bien enviées et pas interprétées à cause d'une mauvaise syntaxe, ou si elles ne sont pas envoyées à cause d'un problème de tension sur le convertisseur 232/422. Mais ce qui est sur c'est que la caméra ne réagit pas.

Pour la syntaxe, j'ai essyé:
serial.print("#O1\n");
serial.print("#O1\r");
serial.println("#O1");

Rien n'y fait. Si vous voyez autre chose, je suis preneur Bien sur.

Par contre je ne sais pas si cela veut dire quelque chose mais.
Je convertisser 232/422 que j'utilise comporte deux LEDs. Une pour la tension (présente ou pas) l'autre pour les Datas.
La 1ère s'allume des que la connexion est établie. L'autre clignote lors du transfert de données.
Ces LEDs s'allument normalement lors d'une connexion caméra /hyperTerminal. Mais ne s'allument jamais lors d'une tentative de connexion Arduino / Camerra.
Par contre j'ai monté deux LED côté TTL. La LED TX clignote normalement lors de l'envoi de données.

Voilà. Les choses avancent. Mais ça ne marche pas encore wink Le progrès ne veux pas dire succès et même si les progrès sont palpables, je n'en suis pas encore au succès. Ça va venir j'espère.

Demain je vais tester un LoopBack côté 422 avec des commandes envoyées par Arduino.
Donc la manipe consisterait à:
- Connecter Arduino au MAX232
- Connecter le MAX232 à un convertisseur 232/422
- Boucler RX et TX côté 422
- Envoyer par un serial.print des commandes par Arduino
- Lire (ou tenter de lire) ces commandes sur un LCD côté Arduino.

Je ne peux pas connecter l'Hyper Terminal lorsque le MAX232 et branché. Le port est occupé.
Par contre je pourrais utiliser une Mega et connecter le port0 au MAX232 et le Port1 à HyperTerminal. Je ne lâcherais pas l'affaire tant que cela ne marchez pas.
Autre manipe à tester (si c'est un problème de tension).
J'utilise pour le moment un convertisseur 232/422 passif. Donc pas alimenté. Je testerais bien avec un convertisseur actif, donc alimenté.
Cdlt
Yves

25

Re : Pilotage caméra

Bonjour

Les choses avancent toujours mais aucun résultat permettant de dire que cela marche.

J'ai réussi à voir via des LEDs côté 422 les Datas passer. Mais impossible de démarrer cette cam en 422 ;(

Avez vous un lien qui explique précisément ce mode de transfert ?
TTL / 422 ?

La les choses se compliquent. J'étais certain d'y parvenir et je ne pensais pas que cela poserait autant de problèmes. Alors je me suis engagé et me retrouve coincé ;(

Si vous pouvez maider …
Merci