Deltakap a écrit:Le problème de conflit entre les librairies Servo et NewSoftSerial est quasiment invisible pour moi à l'usage puisque je "detach" les servos après chaque mouvement (à l'origine pour diminuer la consommation).
Deltakap a écrit:Sinon, à noter quand même, NewSoftSerial a l'énorme avantage de disposer de la fonction available.... rien n'empêche donc de développer avec NewSofSerial puis de repasser sur le vrai UART du microcontroleur (avec la fonction Serial) dès que tout semble ok (aux éventuels problèmes de conflits près) et qu'on est prêt à envoyer tout ça en l'air.
rdd a écrit:Est-ce qu'à votre connaissance il y a des différences sensibles entre les deux modes de fonctionnement UART ou SoftSerial ? Par exemple en terme de performances ?
rdd a écrit:Pour les cartes qui disposent d'un port "APC220/Bluetooth" (la Romeo, le shield IO de la Uno ....) la question ne se pose pas il reste tout de même plus naturel d'utiliser la lib Serial
Deltakap a écrit:rdd a écrit:Pour les cartes qui disposent d'un port "APC220/Bluetooth" (la Romeo, le shield IO de la Uno ....) la question ne se pose pas il reste tout de même plus naturel d'utiliser la lib Serial
Oui, dans ce cas, aucun intérêt de s'embêter avec ces gestions soft de port série.... mais sur mon arduino nano, il n'y a qu'un UART... coincé donc, sauf de démonter à chaque fois l'APC pour reprogrammer l'arduino et c'est vraiment pénible.
rdd a écrit:et pour le dev, je retire tout simplement l'apc quand je branche l'usb.
J-C a écrit:Enfin, bon, si vous avez des bouts code, je suis preneur.
if (Serial.available()) {
inByte = Serial.read();
// action en fonction du inByte............
}
// zoomkat 10-4-10 serial servo test
// type servo position 0 to 180 in serial monitor
// for writeMicroseconds, use a value like 1500
// for IDE 0019 and later
// Powering a servo from the arduino usually DOES NOT WORK.
String readString;
#include <Servo.h>
Servo myservo; // create servo object to control a servo
void setup() {
Serial.begin(9600);
myservo.attach(7); //the pin for the servo control
Serial.println("servo-test-21"); // so I can keep track of what is loaded
}
void loop() {
while (Serial.available()) {
delay(10);
if (Serial.available() >0) {
char c = Serial.read(); //gets one byte from serial buffer
readString += c; //makes the string readString
}
}
if (readString.length() >0) {
Serial.println(readString); //so you can see the captured string
int n;
char carray[6]; //converting string to number
readString.toCharArray(carray, sizeof(carray));
n = atoi(carray);
myservo.writeMicroseconds(n); // for microseconds
//myservo.write(n); //for degees 0-180
readString="";
}
}
Deltakap a écrit:On peut par exemple décider de tout coder sur un seul octet (byte). C'est ce que j'ai fait jusque là, l'inconvénient étant un codage de tilt sur 64 positions seulement, ce qui fait un déplacement pas très "smooth", mais largement suffisant en pratique.
Deltakap a écrit:Le signal envoyé sera une chaine comme "1:987" où 1 est le device (par exemple 1 pour le tilt, 2 le pan, 3 l'apn, 4 le zoom, 5 l'emetteur vidéo, 6 le canal vidéo, etc, etc.... voui, ça reste ambitieux ) et 987 la valeur à appliquer au device (ici avec une grande précision )
rdd a écrit:Pourquoi 64 ?
rdd a écrit:C'est plus problématique pour le PAN qui pourrait aller de 0 à 360° ... et qu'il faudrait recoder sur 0-254 si on veut rester sur un BYTE.
if (millis()-timer > 5000) {pan_servo.detach();
rdd a écrit:changement de fréquence de l'APC en plein vol
#include <NewSoftSerial.h>
NewSoftSerial mySerial(3, 2);
const int SetAPCPin = 4;
void setup()
{
Serial.begin(9600);
mySerial.begin(9600);
pinMode(SetAPCPin, OUTPUT);
//digitalWrite(SetAPCPin, HIGH);//normal operation
digitalWrite(SetAPCPin, LOW); //set parameters
}
void loop()
{
//mySerial.println("RD"); // lecture de la config réelle de l'APC
mySerial.println("WR 475000 1 9 3 0"); //écriture de la config dans l'APC
while (mySerial.available())
{
char cmdChar = mySerial.read ();
Serial.print(cmdChar); // affiche la réponse de l'APC
}
delay(2000);
}
int set_APCFreq(int freq) {
int inc_byte = 0;
String Response;
String Setting;
digitalWrite(APC_Set_Pin, HIGH);
delay(50);
Response= "";
Setting = "WR ";
Setting += String(freq);
Setting += "000 3 9 0 0";
digitalWrite(APC_Set_Pin, LOW);
delay(5);
Serial.println(Setting);
delay(200);
digitalWrite(APC_Set_Pin, HIGH);
delay(50);
digitalWrite(APC_Set_Pin, LOW);
delay(5);
Serial.println("RD");
delay(200);
while (Serial.available() > 0) {
inc_byte = Serial.read();
Response += String(char(inc_byte));
}
digitalWrite(APC_Set_Pin, HIGH);
Setting = "PARA ";
Setting += String(freq);
Setting += "000 3 9 0 0";
if (Setting!=Response) { return 0; } else { return 1;}
}
rdd a écrit:C'est exactement ce que j'ai fait (en copiant sur toi )
rdd a écrit:arf ... la lib NewSoftSerial n'est pas compatible Arduino 1.0 Obligé de repasser sur Arduino 023
J-C a écrit:Bon je tape l'incruste dans votre discussion.
J-C a écrit:Car si on reste trop longtemps sur haut, on arrive vite en butée.
J-C a écrit:En fait si tu restes bloqué sur le bouton "haut", à chaque cycle, tu envoies l'instruction et à chaque cycle, tu incrémentes ton déplacement, bilan ça bouge vite.
J-C a écrit:Je voulais savoir si quelqu'un avait testé un code faisant communiquer entre eux 2 arduinos via une liaison série RF.
Je viens de ressortir mon matos de test Arduino, mais 2 modules APC220 et d'autres modules RF. J'ai bien envie de tester la librairie softserial pour éviter les conflits (de canards) surtout si je veux piloter des servos.
Enfin, bon, si vous avez des bouts code, je suis preneur.
KickMe a écrit:Concernant le half-duplex, ça ne concerne que les aquittements ?
KickMe a écrit:Plus concrètement est-ce qu'on peut continuer à envoyer des commandes au servo (sans aquittement) pendant que la nacelle envoie des infos (altitude par capteur barométrique) ?
#include <SoftwareSerial.h>
#define rxPin 3
#define txPin 2
SoftwareSerial mySerial = SoftwareSerial(rxPin, txPin);
String command; // String input
char inByte; // Byte input
void setup(){
mySerial.begin(9600);
}
void loop(){
// Input serial information:
if (mySerial.available() > 0){
inByte = mySerial.read();
command+=inByte;
}
// Process command when CR is entered:
if (inByte == 13) { // CR
inByte = 0;
if (command[0]== 1){//SOH
//C'est une chaine de caractères.... agir en fonction
}else{
//C'est une commande de servo
}
command = "";
}
}
hansel a écrit:Est ce que un de vous a fait des tests de portée?
Deltakap a écrit:D'après le site d'Appcon technologies, l'APC220 est donné pour une portée de 600m, l'APC200 pour 200m (à 9600bds)
(et c'est curieux puisqu'ils ont tous les deux la possibilité d'émettre en 20mW et le récepteur à la même sensibilité !?)
rdd a écrit: ... mais ... tu as fait les essais avec l'APC220 ou l'APC200 ?
Deltakap a écrit:KickMe a écrit:Plus concrètement est-ce qu'on peut continuer à envoyer des commandes au servo (sans aquittement) pendant que la nacelle envoie des infos (altitude par capteur barométrique) ?
En même temps, non.... mais on va tricher
En fait, on ne va envoyer les commandes aux servos que si il y a de nouvelles valeurs à envoyer (que si on touche aux manettes. Si il n'y a rien de neuf, l'APC au sol repasse en réception et est donc capable de recevoir des infos de la nacelle. Donc, sauf de s'énerver sur les manettes, on devrait pouvoir rafraichir et afficher au sol les infos qui viennent du capteur.
Dans l'autre sens, les données d'altitude (message très court) ne seront probablement envoyées que toutes les 5 ou 10 secondes, voire plus.... L'éventuel "bloquage" des commandes des sticks sera statistiquement rare (et court). On devrait s'en sortir
Retourner vers L'électronique embarquée et au sol
Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 72 invités