Je pense qu'on a eu les infos nécessaires, je répète mon dernier message:

 

Mais bon oui, pour utilisation simple sans risque pour ta vie privée, etc, tu as déjà eu tous les bons conseils sur ce thread (d'ailleurs même si je suis pas d'accord sur la forme, effectivement Serveurperso a donné a peu pret ce qu'il faut).

 

Mais garder à l'esprit que si ce Pi est connecté sur "ton réseau", il peut être un point d'accès à celui-ci et que surtout, même si la c'est surement suffisant d'avoir juste un mot de passe [...] et tenir à jour sa distrib, suivant ce que tu rajoutes dessus, il faudra bien reconsidérer le tout.

 Quand je dis sans risque pour la vie privée c'est ce qui ressort de ce que nous a dit Donovan.

Le plus compliqué au final, c'est de "s'astreindre" a bien garder à jour son PI, il faut le faire régulièrement.

Ah pardon ya pas de débat, je savais pas qu'il ne fallait pas dire qu'on pense autrement...

Mais bon oui, pour utilisation simple sans risque pour ta vie privée, etc, tu as déjà eu tous les bons conseils sur ce thread (d'ailleurs même si je suis pas d'accord sur la forme, effectivement Serveurperso a donné a peu pret ce qu'il faut).

Mais garder à l'esprit que si ce Pi est connecté sur "ton réseau", il peut être un point d'accès à celui-ci et que surtout, même si la c'est surement suffisant d'avoir juste un mot de passe (franchement ça sert à rien de foutre du RSA, ça apportera plus d'emmerdes qu'autre chose) et tenir à jour sa distrib, suivant ce que tu rajoutes dessus, il faudra bien reconsidérer le tout.

Juste pour pinailler 

 

 

Sur cette box Orange à faire en sorte que le mot de passe par défaut ne soit pas identique pour tout le monde, c'est sécurisé par défaut.

Voila encore une affirmation à la hache qui peut être vrai comme très fausse. C'est comme dire ya HTTPS donc c'est secure...

Arf c'est bien dommage, j'avais bien aimer suivre Pablo.

Bonne continuation dans tous les cas

C'est un débat de sourd en fait...

Moi j'ai jamais dit qu'il faut pas connecter son Pi ou pas.

Par contre, à la base Donovandu88 demande ce qu'il doit faire pour sécuriser un peu son bouzin.

La réponse automatique de dire ya pas besoin de sécurité, moi ça m'exaspère, surtout qu'on ne sait pas quelle est complétement la finalité, mais quand on me parle de CamIP, domotique, je me dis qu'on ne veut pe pas que le flux soit disponible à n'importe qui.

Et plutôt que présenter dans ce sens, le faire dans l'autre, en sensibilisant qu'il y a des risques, dans certains cas très mineurs, et que donc avoir un bon mdp et maintenir à jour sa distrib c'est surement un bon début/suffisant.

Je ne dis rien de plus, et non ya pas amalgame, je bosse toute l'année avec des gens qui font des solutions de sécurité, qui parlent de sécurisé tout le temps mais qui ne sont pas fichu en fait de faire le minimum. Pourtant ça fait (devrait plutôt) parti de leur taf, pas une bidouille dans un coin chez soi.

Donc non, la sécurité info c'est plus que le parent pauvre, on veut faire des trucs qui vont vite, qui sont jolis pis si reste un peu de temps on dit qu'on fait de la sécurité (en plus c'est un peu à la mode) mais tant qu'on se fait pas démonter on continue.

Bref ça coûte pas cher d'expliquer un peu le pourquoi du comment, et ça n'empêche pas de faire un peu de sensibilisation/pédagogie.

Je pense qu'on sera pas d'accord, mais au final c'est que la forme qui me déplait, le fond reste pas déconnant.

Moi j'essaye d'expliquer simplement les choses mais en essayant de me mettre à la place de qqu qui y connait rien (ou pas grand chose). Je maintiens lacher des faut mettre du RSA et ya 0 risques, pis etc. Ben non c'est pas la bonne façon de faire.

Je sais bien que malheureusement sur les forums, la plupart des demande sont en mode fast food, mais c'est pas une raison pour pas prendre le temps d'expliquer un peu les tenants et aboutissant.

J'aurai dit il faut mettre en place une dmz avec deux firewall, mettre en place une authentification forte ou je ne sais quoi, oui ça aurait été stupide, et un manque de relativité.

Et non ce n'est pas un sketch, pour la plupart des gens, scotcher la clé de sa maison sur sa porte d'entrée n'est pas pensable et pourtant c'est à peu pret ce qu'ils font avec tout ce qui concerne l'informatique.

Faut pas se méprendre c'est exactement ça que je critique, surement tu sais ce que tu fais et c'est tant mieux.

Par contre, la majorité des gens ne savent absolument pas ce qu'ils font, et la il faut de la pédagogie beaucoup même, sinon par défaut on retient juste avec un peu de bol RSA ou pire ya 0 risque etc.

Malheureusement, dans certains cas ce sera vrai (même si déjà pour un PI servant à faire de la domotique, je m'amuserais probablement pas à la mettre sur le net), mais ce sera appliqué par certains partout et paf...

La majorité des gens, ils ont une box, et ils se branchent dessus, ils ne gérent pas un routeur encore moins un firewall.

Concernant RSA, oui la clé publique sert à être publique, mais bon le côté public on s'en fout, c'est la partie privée qui est importante, et c'est cette clé privée qu'il faut pour se connecter, ce qui est tout sauf pratique dans le cas voulu, accéder une cam IP ou de la domotique de partout. 

Effectivement un avantage d'utiliser un clé plutôt qu'un mdp, c'est que la génération est "automatique" (même si on peut le faire pour un mdp), par contre logiquement il te faut une passphrase qu'il faudrait dans l'absolu être à minima aussi solide que la clé, et être changée en même temps.

Et la on risque de retomber sur les mêmes problèmes, ou est stocké la clé privée, est ce que la passphrase est suffisante, etc.

Par contre je suis d'accord sur le fait de suivre les recommandations, encore faut il les trouver ce qui n'est pas si trivial.

Je suis d'accord sur les solutions (quoi un peu moins sur le compte root mais ça se discute presque), mais pas vraiment sur la forme.

Vous expliquez (surtout Serveurperso sur ce thread) que ya pas de risques puis après qu'il faut sécuriser un minimum.

Franchement, et je parle d'expérience, c'est malheureusement ce genre de "raccourci" (même si après Serveurperso tu expliques bien le pourquoi etc.) qu'on finit avec des systèmes complétement "passoires".

Dire plutôt les risques ne sont pas énorme, et qu'on cherche pas à se protéger contre de la "grande" cyber-criminalité donc qu'il faut "juste" appliquer des principes de sécurité de base.

Et il faut quand même faire attention, le serveur qui sert que à la domotique, un jour on rajoute les volets ou je ne sais quoi et la le risque augmente (quoi c'est plus dangereux que faire clignoter une lampe).

Et surtout, ce joli serveur à des chances d'être connecté sur la box, et peut servir donc de point d'entrée, surtout que les box sont très loin d'être toujours sécurisées, dernier exemple en date : https://www.lebigdat...le-livebox-noel(et franchement ce genre de failles c'est un gros scandale).

Petit rappel aussi sur la cryptographie, utiliser RSA peut aussi donner une fausse sensation de sécurité vu la taille de clé employée. Malheureusement, la résistance d'une clé RSA est bien moindre que sur des clés symétriques, on estime qu'une clé RSA 1024bits correspond à peine à une clé symétrique de 51bits (c'est l'équivalent de ce qu'on peut obtenir avec un mot de passe aléatoire de 9 caractère choisis parmis maj/min), une 2048 c'est même pas l'équivalent de 80 bits. 

L'avantage étant que si on te voles ton Pi ou que quelqu'un arrive à être dessus, s'il récupère ta clé public, il sera pas beaucoup plus avancé, mais comme ça veut dire qu'il est déjà sur la Pi, en fait il en a surement pas besoin.

L'inconvénient c'est qu'il faut quand même conserver sa clé privée et que si on veut se connecter d'un peu partout c'est compliqué (sauf à utiliser une carte pour stocker la clé ou truc du genre).

Au final un bon mot de passe peut être plus sécurisé qu'une clé RSA 2048bits, pour cela il faut 13/14 caractères parmis MAJ/min/chiffres.

(mais faut pas le dire trop fort, sinon c'est comme ce que je disais au dessus, les gens ne vont retenir que le fait que c'est mieux, et faire nimp apres )

Bref moi j'suis pour dire qu'il faut plutôt expliquer qu'il faut sécuriser plus que pas assez, mais c'est surement un peu de la déformation pro.

Ah oui le sizeof(Double) est pas beau D'ailleurs le sizeof(int) de la ligne du dessus est pas forcément toujours vrai, le premier c'est la taille de N pointeurs (souvent de la taille d'un int mais bon faut faire gaffe), bref un sizeof(int*) serait mieux.

Bah en fait le malloc il est pas à prendre en compte, c'est la fonction que tu veux réutiliser, l'initialisation du tableau c'est pour l'exemple.

Ce que j'aime bien dans cette solution c'est le fait de pouvoir utiliser qqc qui rappelle vraiment un tableau à deux dimensions et l'utiliser comme tel.

Pour la petite précision, effectivement on peut mettre "int t[l][c]" plutot que "int t[][c]", mais dans l'absolu ça ne sert à rien d'avoir la taille de la première colonne, on le voit quand on y accède de la façon "t[i*c+j]" qui n'utilise pas le nombre de ligne.

Après un peu de réflexion, je pense qu'on ne pourra pas utiliser un tableau static (int[][]) en entrée sur un int**, même si l'un peut se faire passer pour l'autre, dans l'absolu ces deux déclarations n'ont pas la même sémantique au final, l'un est vraiment un tableau (donc un espace mémoire de nbLigne*nbColonnes continu), l'autre un pointeur qui pointe sur un pointeur qui pointe vers un entier.

Même si j'ai pas eu bcp de temps, j'ai bien aimé, ça faisait longtemps que j'avais pas trop réfléchi à comment ça marche en vrai, et c'est la que je vois qu'il me manque quelques notions sur le fonctionnement interne du C.

En me répétant...

Ben la réponse "facile" c'est de savoir ta consommation moyenne puis après ben tu regardes ce qu'il faut pour tenir 10.5h.

Ex: tu trouves que ton moteur en croisière consomme 20W en instantané, pour 1h il faudra une batterie d'au moins 20W.h, pour 10h 10 fois plus.

Ya rien à "simuler", la batterie nécessaire est celle qui à la puissance moyenne consommée dure 10.5h, une fois la conso connue, faut faire une multiplication quoi...

Un malloc et on en parle plus hein

mais même sans on peut faire relativement propre, même si le paramètre sera un int * et non int**:

// Passage d'un tableau à 2 dimensions (fonctionne !)
const int l=3;
const int c=2;
int t[l][c]= {{0, 1},
              {2, 3},
              {4, 5}};
void setup() { 
  Serial.begin(9600);
  readtab(&t[0][0], l, c);
  Serial.println();Serial.println();Serial.println();Serial.println();
  readtab((int *)t, l, c);
}
void loop() {}
 
void readtab(int *tab, int lg, int cl){
  for(int i=0; i<lg*cl; i++){
      Serial.print(tab[i]);
      Serial.print(" ");
  }
}

La version avec malloc et l'utilisation d'un int** (on peut faire avec un int* comme au dessus, mais faut changer les malloc):

// Passage d'un tableau à 2 dimensions (fonctionne !)
const int l = 3;
const int c = 2;
int t[l][c] = {{0, 1},
  {2, 3},
  {4, 50}
};
void setup() {
  Serial.begin(9600);
  int** myTab = malloc(l * sizeof(int));
  for (int i = 0 ; i < l ; i++) {
    myTab[i] = malloc(c * sizeof(double));
  }

  for (int i = 0; i < l; i++) {
    for (int j = 0; j < c; j++) {
      myTab[i][j] = t[i][j];
    }
  }

  readtab(myTab, l, c);
}
void loop() {}

void readtab(int **tab, int lg, int cl) {
  for (int i = 0; i < lg; i++) {
    for (int j = 0; j < cl; j++) {
      Serial.print(tab[i][j]); Serial.print(" ");
    }
    Serial.println();
  }
}

C'est effectivement une solution, mais moi j'aime pas trop le fait de conceptuellement passer le tableau de 2 dimensions à 1, même si ça devrait fonctionner partout.

Dans ce cas on sous entend que la représentation mémoire du tableau à deux dimensions est linéaire (en fait une dimension), mais je ne suis pas sur que ce soit obligatoire en C (ie que le langage C impose de représenter un tableau multi dimension ainsi).

Sinon je viens de tester:

const int l=3;
const int c=2;
int t[l][c]= {{0, 1},
              {2, 3},
              {4, 5}};
void setup() { 
  Serial.begin(9600); 
  readtab(t, l, c);
}
void loop() {}
 
void readtab(int (*t)[c], int lg, int cl){
  for(int i=0; i<lg; i++){
    for(int j=0; j<cl; j++){
      Serial.print(t[i][j]);Serial.print(" ");
    }
    Serial.println();
  }
}

fonctionne bien comme prévu. et on peut remplacer le "int (*t)[c]" par "int t[][c]" qui est identique.

En fait j'ai regardé rapidemment, mais tout doit venir d'un problème de typage, même si un tableau à la fin c'est du pointeur, int** c'est un pointeur de pointeur sur int alors que int[][] c'est bien un tableau à deux dimensions de int.

Et ce problème n'est présent que parce que le tableau est alloué statiquement en varibale "globale". Avec un malloc on aurait pas de soucis (bon après pour remplir le tableau c'est moins joli je sais).

J'essaye de voir comment en castant ou autre on peut faire une vraie utilisation de tableau à partir d'un double pointeur mais ce n'est pe pas possible.

Dans tous les cas pour moi la solution la plus propre est de donner la deuxième dimension en entrée de la fonction, c'est la bonne sémantique en C  qui demande que toutes les dimensions sauf la premières doivent être données pour l'initialisation d'un tableau statique.

Ben tu as dans tous les cas la possibilité de déclarer un peu plus finement to tableau dans la fonction:

void  Kinematic(int lg, int tb[][nbFeet], int nsrv, int vel, int foot, int *srvadjust){

Normalement ça c'est valide et comme ton tableau est déclaré en utilisant cette constante, ça me semble être ce que tu veux.

J'ai pas de quoi tester sous la main, je regarderai demain pour quoi les autres façons ne fonctionnent pas...

Ya aussi la solution du malloc pour ton tableau, la le passage par int** devrait fonctionner avec [][].

Moi tout me va

Mais sinon, je trouve toujours tes notations moins compréhensibles, je parle des notations du genre

*(tb+(srv*lg)+i)

qui peuvent plus facilement s’écrire

 tb[srv][i] (ou un truc du genre)

J'ai toujours trouvé que l'écriture par pointeur pour accéder à une case de tableau peu compréhensible. Surtout quand on commence à utiliser un tableau en deux dimensions (ou plus).

Si on reprend la ligne complète ça donne:

if ( *(tb+(srv*lg)+i) >= *(tb+(srv*lg)+i+1)

VS

if ( tb[srv][i] >= tb[srv][i+1] )

Ben moi je trouve la deuxième version plus explicite, c'est bien un tableau qu’on utilise pas juste un entier dans un espace mémoire.

De même pour alléger l'écriture et faciliter la lecture/maintenance (et les performances), ton "*(tb+(srv*lg)+i)", comme tu l'utilises plusieurs fois, autant le mettre dans une variable locale, certes ça prendra de l'espace mémoire, mais ça sera plus rapide vu qu'on évite 2 additions et une multiplication (c'est long les multiplications).

Tout cela c'est pas forcément mieux, surtout la forme d'écriture suivant les habitudes.

Ah oui tu n'alloues pas le tableau dynamiquement, dans ton cas ton type est un int(*)[2] et non un int** donc ça va pas vouloir compiler effectivement.

Juste sans alourdir le tout, un int** c'est un pointeur de pointeur, int(*)[2] c'est un tableau de 2 pointeurs sur des int* (quand on lit un type de variable on part de la droite pas de la gauche).

Et int(*)[2], ça s'écrit aussi int[][2]. 

Sans être sur sur, si tu cast a l'appel de la fonction avec un (int**), ça devrait être bon (programmatiquement j'suis sur, pour le résultat je pense que ça marche).

Sinon tu peux aussi allouer dynamiquement ton tableau avec un malloc et la tu auras bien un type int**, donc le typage sera homogène.

(Quoi un malloc renvoie en vrai un "void*", qui est un pointeur générique sur n'importe qu'el type, donc c'est n'importe quoi, comme le int**, mais aussi n'importe quell pointeur en fait )

Quand on alloue en "dur" un tableau à deux dim (ce que tu fais vu que tu utilises des const pour sa taille), il faut au moins passer la taille de la deuxième dim (souvent dite colonne) pour que le compilo soit cool.

Salut,

Et si tu changes

void readtab (int tab[0][0], int l, int c) {

en

void readtab (int** tab, int l, int c) {

Ça devrait marcher, et la de toute façon pour moi tu es dans le cas ou il faut passer par des pointeurs (façon int tab[8] ou int* tab, du point de vue du compilo c'est en gros la même chose, un pointeur vers une zone de données avec des int dedans ).

Comme j'avais expliqué au dessus, le passage par valeur, on le fait surtout pour des types primitifs, pour le reste (tableau, structures, etc), vu que ça risque d'être gros c'est mieux par référence comme ça on risque pas de faire exploser la pile.

A voir hein, mais en regardant rapidos la vidéo, j'ai des doutes c'est trop "beau" pour être vrai.

Moi je tenterais quelque chose de ce genre la :

http://makerspace56.org/comptage-par-franchissement-dune-barriere-infrarouge/

C'est simple à mettre en oeuvre, si tu veux une bonne couverture tu mets deux diodes et 3 recepteurs en face.

Sachant que le point "important" est que le récepteur (ici TSOP32138) qui est un récepteur qui "filtre" sur une porteuse (pour faire des télécommandes en fait). Ça permet d'être un peu plus résilient au bruit ambiant.

Après si le capteur est complétement directement par une lampe, ça marchera moins bien.

Par contre avec de l'ir c'est surement moins directif quand même (quoi que avec des petit cylindres devant les led pe...) donc j'équiperais plutôt chaque case. Mais bon même avec 3 récepteurs, ont doit rester sous les 5€.

Faut voir si ça fonctionne bien mais je me dis un recepteur au milieu et 2 de chaque côté de celui ci vers 15cm du premier, ça dvrait détecter une main.

Mais ça reste a tester quand même le réseau même sans laser ou diode tres directrice, mais ce sera surement difficile d'avoir de la précision, on peut surement améliorer la précision en utilisant des porteuse différentes mais la faut faire gaffe au problème d'interférences.

Bonjour,

Pour fair de la détection d'entrée dans les cases, le plus simple reste de faire une "barriere laser", c'est très directif et à chaque fois qu'on coupe le faisceau (pe avec une hystérésis pour éviter de détecter plusieurs fois le même ajout), on ajoute un.

Attention avec des capteurs US, il ne faut pas qu'ils se perturbent, suivant l'agencement des cases ça peut être un problème.

Bien sur pour chaque case il faudra pouvoir détecter, mais si les cases sont toutes contigues, il suffira de faire un réseau de capteur (un par case sur la longueur et un par case sur la largeur) en croisant les détections on connait la case.

Sur 32 case en 8*4 par exemple on n'a besoin au final que de 12 détecteurs au lieu des 32.

A voir si il faut vraiment des lasers ou juste des leds haute luminosité directives, mais dans tous les cas même les diodes lasers très faible puissance ne coutent pas trop cher il me semble.

Mais si tu peux passer par des leds infrarouges (genre télécommande quoi), la ça ne coute que quelques cetimes la led et idem pour le récepteur et c'est minuscule.

Ce n'est pas de la robotique, mais c'est tellement énorme que je n'ai pas résisté.

C'est une video issue d'un simu de vol non?

Le son semble très étonnant, quadn ils jouent à la "fusée" pas une poussière, etc.

Bon après même si c'est vraiment sur simu, ça n'enlève pas qu'il faut savoir piloter ce genre d'engins...

Salut,

Ben la réponse "facile" c'est de savoir ta consommation moyenne puis après ben tu regardes ce qu'il faut pour tenir 10.5h.

Ex: tu trouves que ton moteur en croisière consomme 20W en instantané, pour 1h il faudra une batterie d'au moins 20W.h, pour 10h 10 fois plus.

Le plus imprécis dans tout cela sera d'estimer la pente moyenne et la vitesse moyenne, la consommation ne sera pas la même pour 1% et 3km/h ou 6% et 7km/h.

Si vous êtes en terminal, il va peut être falloir à minima expliquer les forces s'appliquant sur votre chariot pour expliquer la consommation "prévue", sinon ya aussi google qui donne la consommation pour une masse, vitesse, pente, accélération (qui doit surement pouvoir être oubliée si on considère que la marche est longue et presque régulière) et quelques autres paramètres (qui vous seront difficillement quantifiables, comme la résistance à l'avancement dues aux roues et le chemin, à l'aérodynamisme même si à cette vitesse c'est plus que négligeable, etc)

Attention quand même, si tu calcules la pussiance nécessaire pour faire avancer le chariot dans les conditions prévues, il faudra rajouter les "pertes" de la chaine de transmission (le moteur à une certaine efficacité, son controleur aussi) et prévoir un peu de marge parce qu'une batterie aura du mal à débiter sa capacité totale.

Je suppose que cdcf = cahier des charges fonctionnels?

Dans tous les cas, attention, pour moi vous commencez mal, si votre chariot est à l'échelle 1/3, oui les dimensions sont divisées par 3, mais non ça ne veut pas dire que le poids est seulement divisé par 3.

Juste pour l'exemple extrême, prend un cube d'1m de côté rempli d'eau. On a donc 1000L soit 1 tonne d'eau. A l'echelle 1/10, on a un cube de 10cm de côté, soit 1litre d'eau ou 1kg. Bref on a un facteur 1000 sur le poids, ce qui est facile à comprendre, on a divisé par 10 mais sur 3 dimensions, et 10³ = 1000.

(Pour une surface c'est donc le carré de l'échelle, pour une surface le cube)

Bref tout cela pour dire que votre chariot si il était plein devrait subir une réduction de poids d'un facteur 3³ = 27, dans la vraie vie, il y a du vide, donc le poids ne sera pas autant diminué, mais serait bcp plus faible que juste 3 fois moins.

Idem pour le poinds transporté, il pourra surement contenir un volume 27 fois moindre donc un poids environ 27 fois moindre.

Par contre pour la viteese, on applique le facteur d'échelle si on veut conserver la même impression de vitesse (la vitesse peut être exprimées en longueur du chariot par unité de temps, si la longueur diminue, la vitesse diminue proportionnellement).

Oula attention, je dis pas qu'il ne faut pas utiliser les pointeurs, les pointeurs c'est une adresse en mémoire (que ce soit dans la pile ou dans le tas).

Il y a beaucoup de cas où c'est utile voir indispensable, mais je maintiens si on veut passer une information genre un entier dont on ne veut pas conserver les modifications, un pointeur est inutile.

Quand on écrit une fonction on peut passer les paramètres de deux façon:

• par valeur: c'est le cas par défaut (sans pointeur quoi), dans ce cas le paramètre passé est une copie du paramètre dans la fonction appelante (mère). Toute modification de celui ci ne sera donc pas visible en dehors de la fonction fille. 
• par référence: avec un pointeur. La on passe l'@ mémoire ou est stocké la donnée, si on modifie cet espace mémoire, la modification se faisant sur la valeur "initiale", même en sortant de la fonction fille, la modif est gardée.

En pratique on utilise le passage par valeur que sur des types simples, sinon la recopie de la valeur coute du temps et surtout de la place mémoire (en pile). Quoi après ça dépend pour le temps, puisqu'on ajoute une indirection (on à l'adresse de la valeur pas la valeur directement, donc il faut d'abord lire l'adresse puis y aller), dans ton exemple je suis presque sur que ça perd du temps (après faudrait mesurer pour être sur), en règle générale ça gagne du temps de passer par référence (au moins sur l'appel de fonction).

Pour linux / WIndows oui c'est (en partie) du C, un exemple (le premier fichier C dans le kernel, je connaissait meme pas son existence) dans le kernel : https://github.com/t...r/kernel/acct.c, regarde la fonction  check_free_space (ligne 101), le paramètre est un pointeur parce que dans le code on modifie l'objet passé (par exemple ligne 116/123/128) et aussi parce que c'est surement un objet créé dans le tas.

Par contre dans ce même fichier ligne 315, la fonction encode_comp_t prend en paramètre un long directement, parce que dans ce cas la valeur n'étant pas modifié dans la fonction c'est plus simple.

Par exemple, le passage par valeur des paramètres:

int maFonctionParValeur(int valeur) { 
  valeur++;
  return valeur
}

Le passage par référence sera:

int maFonctionParReference(int* valeur) { 
  (*valeur)++;
  return *valeur
}

Maintenant, considérons le programme appellant suivant:

int val = 0;

print(maFonctionParValeur(val));     // On affiche ce que retourne la fonction, ici 1

print(val);                          // on affiche ce que vaut notre variable val, ici 0
                                     // la fonction précédente n'a pas changé notre variable

print(maFonctionParReference(&val)); //on affiche ce que retourne la 2eme fonction, ici 1

print(val);                          // on affiche ce que vaut notre variable val, ici 1
                                     // parce "val" a été passé par référence et non par valeur

Moi franchement je ne suis pas dogmatique mais plutôt pragmatique. Je ne sais pas si les pointeurs sont ou ne sont pas à la mode, de toute façon ils sont nécessaires (que ce soit en Java, même caché ou un langage comme C ou c'est très visible), et c'est vrai dans tous les langages ou on peut gérer la mémoire.

Les pointeurs sont pratiquement obligatoires sur un programme, mais il vaut mieux les éviter quand pas nécessaire.

Le cas le plus courant c'est par exemple si dans ton code au lieu d'appeller Kinematic avec toutes les références 

Kinematic(&lgTab, Tab1[0], &nbSrv, &Speed, &Foot, &SrvAdjust[0] );

tu oublies un "&", la c'est le drame, un gros risque d'avoir la fameuse "Segmentation Fault".

Evidemment dans ton cas le code est suffisamment petit pour que ce soit facilement détectable, sur un gros projet ça peut devenir un peu plus compliqué.

Les pointeurs, c'est très intéressant pour faire des boites noires. Nul besoin d'en comprendre le contenu.

Oui dans l'absolu un pointeur c'est une adresse mémoire, ce qu'il y a derrière est dépendant du programme, par contre ce côté justement boite noire est vite "dangereux" pour la compréhension, la maintenabilité (et la sécurité), etc.

Passer des pointeurs sur des entiers n'a pour moi d'intérêt que quand on veut travailler sur la valeur d'origine et non sur une copie de la variable. Dans ton cas, tu passes juste des longueurs qui ne sont pas changées, le pointeur ne fait qu'alourdir beaucoup les notations et demande plus de "travail" au processeur pour éxécuter le programme (bon sur un exemple simple c'est pas trop grave, mais si on complexifie les choses, ça dégrade les performances, sauf si le compilo est suffisamment intelligent pour optimiser cela mais j'en suis pas sur).

A noter aussi que souvent un int * toto en C c'est une des manière de déclarer un tableau, ça peut aussi porter à confusion.

Au début, je vais sans doute un peu tricher, mon quadruped sera programmé pour monter mes escaliers qui somme toute sont standard.
Après, on verra. Mais ce ne sera déjà pas si mal. Non ?

Ah oui hein loin de moi de dire que ce n'est pas bien ce que tu fais, comme dit dans mon message précédent j'apprécie lire tes avancées, problèmes, résolutions c'est super et faut continuer

Et tu as raison il vaut mieux commencer par simplifier puis aller en complexifiant, je me disais juste que comme tu as maintenant la base, tu pouvais améliorer certains points. Et aussi que suivant la précision mécanique, je me demande si une cinématique toute prédéfinie sera suffisante mais la justement si tu le testes on saura

Sympa le résultat même si tu pourrais encore bcp l'améliorer, par exemple (et ça peut servir pour le quadrupède grimpeur), ne pas dépendre d'une cinématique complètement fixe mais s'adapter (un peu) aux conditions.

Certes c'est compliqué je pense mais pour monter les escalier je me dis qu'une cinématique complètement fixée ne fonctionnera pas bien...

Pour le programme, j'ai l'impression que tu te compliques quand même franchement la vie, du moins ça me semble bien compliqué (ou c'est moi qui n'ai rien compris ), quoi c'est surtout l'utilisation de pointeurs qui alourdissent les notations. Moi j'applique toujours le paradigme "un pointeur sauf si nécessaire = problèmes".

Je ne comprends pas pourquoi tu dois avoir 3 boucles imbriquées pour parcourir ton tableau à deux dimensions. Dans ma compréhension, tu a une ligne par servo, chaque ligne a les différentes positions (finales il me semble), et donc tu mets à jour chaques servo puis passe à la valeur suivante. Mais pour cela une double boucle imbriquée devrait suffire donc qqc doit m'échapper...

Dans tous les cas continues tes recherches j'aime bien lire l'évolution

Pour pouvoir sortir plus vite ses petits chevaux?