Mon premier multirotor avec raspberry

Guillaume22

C.est bien tu t.es renseigner mais les petits avion n.ont pas de transporteur donc la regle de ne pas monter au dessus de 150 mètres partout est importante

Envoyé de mon truc avec mes machins

Ovopack · Message non lu par **Ovopack** » jeu. 4 déc. 2014 11:45

De toute façon, je n'en suis pas encore là

Vu le type de l'espace aérien où je suis (C ou D), le transpondeur est obligatoire donc je peux suivre les avions. pourquoi pas ne pas en mettre un sur le drone car c'est un radar passif (amical) dans la zone où je suis. Mais bon, je suis à l'exact perpendiculaire d'un couloir aérien à plus de 5km... A voir!

Pas de vidéos hier car pas grand chose de nouveau à montrer.

- La caméra est installée, sans servo pour le moment et interfacée avec le raspberry.
- Le pc de control est configuré pour la réception de la caméra, avec un minium de latence (< 150-200ms, ce qui est pas trop mal). Je pense pourvoir le diminuer encore + en passant par de l'udp plutot que le tcp et en réduisant la résolution.
- Le yaw du joystick est interfacé

Coté servo, test à mi-puissance : incontrolable!
Les parasites dans les sorties de controles du rapsberry font que les moteurs sont complétements instables. J'ai trouvé d'où viens la source : une régulation logiciel!
C'est en fait le processeur principal du raspberry qui gère le GPIO (les sorties de control pour les servos et ESC) et non une puce dédiée sur le raspberry ce qui cause, quand le raspberry est occupé (programme de calcul, envoi de la caméra, etc....), des temps de latence et "des ratés" dans la modulation de puissance.
Conclusion, il me faut donc une régulation MLI en temps réel (hardware PWM). Pour ca, pas d'autre moyen : acheter une carte qui se chargera de ca, et controlable via le protocol I²C (d'autres broches du GPIO). Le but, envoyer une seule fois en numérique l'ordre de vitesse et laisser la carte de controle se charge de la modulation en hard.

http://www.adafruit.com/product/815" onclick="window.open(this.href);return false;

C'est commandé, j'attends de la recevoir, de l'interfacer, la programmer, relirer les servos et esc et reprendre où je m'en suis arreté.
La puce GPS est commandée et arrive. Idem pour les gyros, j'ai perdu du temps avec un revendeur de m****, mais elle arrive aussi.
Les cartes wifi et batterie du raspberry sont encore à acheter.

A suivre :
- montage de la cam sur le servo + interface avec le joystick pour le control.
- calcul et programmation à faire pour la régulation de la stabilité
- ajout du réglage de la sensibilité du joystick
- ...

Guillaume22

chapeau bas

Ovopack · Message non lu par **Ovopack** » dim. 7 déc. 2014 23:04

Petite nouvelles du front :

Concernant les cartes,

GPS : (GPS ULTIMATE, de adafruit je crois), commandée initialement chez mchobby mais commande annulée. Pas réactif, ils marquent un gros Livraison gratuite ! pour se prendre ensuite 7€90 dans la vue pour.... mondial relay!!! A ce prix la, c'est de l'UPS 24h!!! Annulée! Du coup, pas urgent, je recommanderai plus tard, surement en groupant chez amazon.

L'altimu (gyromètre) : De chez pololu (US), ca traverse l'atlantique et ca devrait arriver... commandé directement chez le fabricant cette fois-ci, voir mon coup de gueulle dans la rubrique.

Carte PWM (contrôle servo) : De chez Adafruit, arrive par amazon.

Entre temps, j'ai eu le temps de cogiter pour la nouvelle baterie du raspberry pi que j'avais déglingée d'un coup de tournevis.
N'y a-t-il pas moins cher que de racheter ca (dans les 40€) et une solution moins lourde?

La réponse :

J'ai trouvé ca sur amazon. Commandé la veille, recu le lendemain, sans frais de port. J'adore vraiment amazon!
C'est un régulateur de tension variable : sur n'importe qu'elle tension d'entrée, il me sortira celle réglée sur la vis. Encore mieux, il y a un multimètre, commutable entre l'entrée et la sortie!!
Celui de adafruit (10€) me paraîssait trop "cheap" et n'était de toute façon pas en stock

Pourquoi un régulateur? Tout simplement pour alimenter le raspberry directement sur les batteries des moteurs!

Avantages ?
- 9€25 ....
- très léger
- et surtout pas besoin de sur-dimmensionner la batterie (donc encore plus lourd) pour être sûr que l'ordinateur sera alimenté plus longtemps que les moteurs

Inconvénient?
- ...

Du coup cela va plus pomper sur les batteries des moteurs. MAIS!!!! vu le poids de la batterie du rapsberry (poids d'un gros smartphone tout de même), je ne pense pas qu'il y ai besoin de faire un calcul pour savoir s'il vaut mieux une batterie supplémentaire quitte à tirer comme un taré sur les moteurs pour la soulever ou prendre juste un peu plus de jus sur la batterie principal...

Adepte du rapport poids/puissance (sur les trucs à 4 roues et d'une tonne

), je connais l'impact du poids et surtout comment il est facile de le diminuer comparé à l'augmentation de la puissance. J'ai donc privilégié le poids et certainement fais un bon gain d'autonomie.

A suivre

Guillaume22

On utilise beaucoup ce qu.on appelle des bec en modélisme, vu que l.on a de la video en 12 volt, de l.electronique en 5 volt et de la puissance entre 12 et 24 volts.

Envoyé de mon truc avec mes machins

Ovopack · Message non lu par **Ovopack** » dim. 7 déc. 2014 23:15

Ah oui tient, j'ai oublié d'en parlé :
J'ai bien 3 BECs, 1 par moteur le seul soucis c'est qu'ils sont en 5,5V. Le raspberry est censé bien fonctionner en entre 4,7 et 5,2V.
300mV dans le monde de l'électronique simple, c'est un peu limite mais pourquoi pas... Pour quelque chose d'aussi sensible qu'un ordi, sans protection... ca ne passe pas.
Et je n'ai pas confiance, ils doivent être assez stable pour les RX et servos mais je crains fort les pics de tension ou autres joyeusetés de ce genre qui bruleraient mon processeur et metterai mon drone à terre!

Donc, UBEC! En plus, celui-ci, fonctionne avec une alimentation à découpage (la tension est bien lisse), je ne sais pas quel procédé utilisent les BECs interne mais ca ne doit pas être du haut de gamme

Guillaume22

On utilise pas trop les bec des esc ils sont en effet peu fiable et avec des tensions mal lissé

Envoyé de mon truc avec mes machins

Guillaume22

http://www.flashrc.com/121-bec_regulateur_tension.html" onclick="window.open(this.href);return false;

Envoyé de mon truc avec mes machins

Ovopack · Message non lu par **Ovopack** » jeu. 11 déc. 2014 12:39

Des nouvelles, des bonnes et... aussi des mauvaises

:

La carte adafruit est arrivée, celle qui me permet de générer de la PWM (commande puissance) en hardware.
L'interface numérique (i²C) est faite avec le raspberry. Raccordement d'un servo et d'un ESC...
Les tests sont faits, ca fonctionne impec : plus de démarrage intempestif, plus de parasites, courbe de puissance bien lissée, ... bref ca répond à la perfection.
Tout est réglé de ce côté.

L'altimu de pololu est aussi arrivé [yahoo.gif]
Malheureusement je n'ai pas eu le temps de l'interfacer car pendant une toute petite vidéo sur les tests de la carte adafruit, un fils de masse à touché le raspberry et ...

Dégouté.

Du coup, le nouveau raspberry (modèle A+ cette fois ci, plus petit, léger et moins gourmand) arrivera samedi. Entre temps, des broches de breadboard (pour du cablage facile) sont arrivés pour un cablage plus safe la prochaine fois.

Les cartes wifi awus036h (1000mW !!!!) de chez alpha sont aussi elle en route.

Restent le module GPS et des pièces de rechange de chez Hobbyking (3autres batteries, les miennes ont eu droit à quelques court-circuit rapides mais reste utilisable, 1 ou 2 moteurs, des hélices 16", et cela devrait suffire).

Je profite du temps libre pour revoir le coté matériel :
- mousse pour éviter les vibrations de équipement,
- positionnement des cartes,
- revu du cablage
- perfectionnement de l'axe du yaw

YouTube · Message non lu par **Dehas** » jeu. 11 déc. 2014 12:59

Désolé pour ton Raspberry, merci pour ton partage.

rn3 · Message non lu par **rn3** » ven. 12 déc. 2014 09:44

Encore bravo pour ton boulot , moi je suis largué mais je continue à lire

Ovopack · Message non lu par **Ovopack** » mer. 17 déc. 2014 14:29

Avant la cata :

La carte adafruit était arrivée (et vu l'état de l'enveloppe, elle en a vu du pays...) :

La carte polulu Gyro + baro, idem (la taille m'a quand même fait bien sourire) :

Test d'interfacage :

Et c'est là que la fin du raspberry avait sonné

Sur ce, de retour un peu plus en forme et avec le matériel :

Le nouveau raspberry (mieux adapté cette fois, l'ancien est dessous pour comparer):

Les cartes wifi (mais je continu d'utiliser le dongle en intérieur) :

Installation du nouvel ordinateur :

Finalement, repose sur le multi, cablage des nouvelles cartes et c'est reparti :

Ovopack · Message non lu par **Ovopack** » ven. 19 déc. 2014 12:57

Je rencontre de gros problèmes en ce moment au niveau de l'AltIMU-10 v4 (gyromètre, accéléromètre, magnétomètre et baromètre).

J'ai à peine réussi à l'interfacé avec le raspberry (via des exemples de programmes python tout fait). J'en ai récupéré quelques données mais soit en dégré mais uniquement pour le gyro, je ne peux donc pas compenser la dérive avec l'accéléromètre et j'obtient de gros écart après quelques mouvements, soit des données bruts pour les deux mais je ne sais pas les convertirs en angles...

Dernière chance, une librairie en C mais avec une interface utilisable en python : https://github.com/richards-tech/RTIMUL ... nux/python" onclick="window.open(this.href);return false;
Je test ce soir en espérant en tirer quelque chose.

Passage obligatoire malheureusement, même en pilotage manuel, ne serait-ce que pour garder le bon cap avec le yaw.

YouTube · Message non lu par **Dehas** » ven. 19 déc. 2014 13:02

On peut dire que tu as une sacrée patience, je te souhaite bien du courage pour la suite.

Ovopack · Message non lu par **Ovopack** » ven. 19 déc. 2014 13:10

Là je suis apparement arrivé à la limite de mes compétences donc je n'ai pas le choix de les augmenter pour continuer, en espérant y arriver.
Cette librairie a l'air prométeuse car l'auteur précise une complète compatibilité avec ma carte. Je croise les doigts.

Il est vrai que je pense de plus en plus à aller plus sur du tout fait mais le budget n'est pas du tout le même, l'apprentissage non-plus, n'aura très certainement pas les caractéristiques demandées et rien ou peu sera modifiable selon volonté et besoin, logiciel comme matériel.
C'est ces raisons qui me font tenir bon.

stiff33160

il me semble avoir lu quelque part que faire un engin volant avec une raspberry était non faisable dû au fait que la raspberry n'a pas de notion de temps (il me semble )
mais tu es tout simplement en train de démontrer le contraire !!

ce que tu fais est réellement intéressant j'attends la suite avec impatience, et ça pour me donner envie de copier ce que tu fais lol

Ovopack · Message non lu par **Ovopack** » ven. 19 déc. 2014 19:58

Je pense que tu parles de l'horloge en temps réel.

De ce que j'ai lu, le raspberry n'est pas équipé d'une horloge en temps réel, qui équipe apparemment tous les ordinateurs.
Elle n'est pas incluse car c'est une puce chère et elle faisait dépasser le budget pour le raspberry donc ils ne l'ont pas incluse.

Cependant, le raspberry agit comme un "cerveau" sur le drone.
Très grossièrement, il récupère les infos des capteurs, fais quelques calculs et envoie le résultat à la carte de contrôle pour les ECS.
Le temps réel (réponse avec une fréquence de 1,5GHz soit 0.000000001s) n'est pas utile ici mais il est vrai que la "boucle" de calcul doit être la plus rapide possible pour être réactif aux changements d'angle.
Je simplifie le programme au maximum et je déleste le processeur et la RAM des programmes inutiles pour accélerer cette boucle.
C'était déjà prévu une mesure du temps moyen de la boucle, une fréquence de 50-100Hz (calculs par seconde) serait très bien soit un calcul tout les 0.02s-0.01s, ca devrait suffisament être stable, je ne prévoi pas que le multi "balance" aussi vite de chaque coté, sauf en cas de tempête, et encore...
Donc pas besoin de cette puce! Et pour être honnête, je ne sais même pas pas dans quelle application elle est utile (raspberry comme ordinateur normal)

SUR CE :

Je viens de tester ce soir la "fameuse" librairie, la dernière chance!!!

J'installe (j'y passe 2h) et.... CA MARCHE PAS!!!!

A non pardon, je n'ai pas su lire correctement le README...

J'installe donc correctement, je teste, je retravail rapidement le programme pour l'affichage, et :

3 axes : roll, pitch, yaw, pression, estimation de l'altitude en fonction de la pression (calcul), et même la température...

[yahoo.gif]

A la fois content que ca marche et dégouté d'avoir passé 3-4 soirées pour rien alors que cette librairie est "Plug-and-Play".

Bon, ca marche quoi...

Maintenant, je vais inclure ca dans le programme serveur (pilote), lier ca avec le joystick, et tester un vol à plat

YouTube · Message non lu par **Dehas** » ven. 19 déc. 2014 20:43

Rien qu'a voir les ligne, j'en ai mal au crane !

stiff33160

Ovopack a écrit :Je pense que tu parles de l'horloge en temps réel.

De ce que j'ai lu, le raspberry n'est pas équipé d'une horloge en temps réel, qui équipe apparemment tous les ordinateurs.
Elle n'est pas incluse car c'est une puce chère et elle faisait dépasser le budget pour le raspberry donc ils ne l'ont pas incluse.

Cependant, le raspberry agit comme un "cerveau" sur le drone.
Très grossièrement, il récupère les infos des capteurs, fais quelques calculs et envoie le résultat à la carte de contrôle pour les ECS.
Le temps réel (réponse avec une fréquence de 1,5GHz soit 0.000000001s) n'est pas utile ici mais il est vrai que la "boucle" de calcul doit être la plus rapide possible pour être réactif aux changements d'angle.
Je simplifie le programme au maximum et je déleste le processeur et la RAM des programmes inutiles pour accélerer cette boucle.
C'était déjà prévu une mesure du temps moyen de la boucle, une fréquence de 50-100Hz (calculs par seconde) serait très bien soit un calcul tout les 0.02s-0.01s, ca devrait suffisament être stable, je ne prévoi pas que le multi "balance" aussi vite de chaque coté, sauf en cas de tempête, et encore...
Donc pas besoin de cette puce! Et pour être honnête, je ne sais même pas pas dans quelle application elle est utile (raspberry comme ordinateur normal)

SUR CE :

Je viens de tester ce soir la "fameuse" librairie, la dernière chance!!!

J'installe (j'y passe 2h) et.... CA MARCHE PAS!!!!

A non pardon, je n'ai pas su lire correctement le README...

J'installe donc correctement, je teste, je retravail rapidement le programme pour l'affichage, et :

3 axes : roll, pitch, yaw, pression, estimation de l'altitude en fonction de la pression (calcul), et même la température...

[yahoo.gif]

A la fois content que ca marche et dégouté d'avoir passé 3-4 soirées pour rien alors que cette librairie est "Plug-and-Play".

Bon, ca marche quoi...

Maintenant, je vais inclure ca dans le programme serveur (pilote), lier ca avec le joystick, et tester un vol à plat

merci pour les precisions !! ton projet est vraiment au top.

Ovopack · Message non lu par **Ovopack** » mer. 24 déc. 2014 16:19

Qui veut avoir encore plus mal à la tête en lisant le programme du raspberry?

Code : Tout sélectionner

from __future__ import division
import os,os.path,time,threading,RTIMU,math,sys,getopt
from Adafruit_PWM_Servo_Driver import PWM
from socket import *
sys.path.append('.')

# Debug
vverbose = 1

def verbose(msg):
	if vverbose == 1:
		print(msg)

verbose("=> Starting script")

# ====================================================================================================
	
# Communication ports
UDP_IP = "192.168.1.99"
UDP_PORT = 5015
UDP_PORT_ACK = 5016
UDP_PORT_TELE = 5017
UDP_PORT_JOYSTICK = 5018

# Pins
pm1 = 0
pm2 = 1
pm3 = 2
pyaw = 3
pledautopilot = -1

# PWM Frequency
freq = 100

# Settings dutycycles
minm = "init"
maxm = "init"
moym = "init"

# Yaw (indifferent about freq)
minyaw = 460
maxyaw = 700
yawinit = 550

minyaw = int(minyaw*freq/100)
maxyaw = int(mawyaw*freq/100)
yawinit = int(yawinit*freq/100)

# Default flight mode : MAN, STAT, FLIGHTROUTE , HOME
flightmode = "STAT"
# Default stat mode : ACC, GPS
statmode = "ACC"
# Default alti mode : GPS, BARO
altimode = "BARO"
# Default sensibility joystick
sensibilite = 0.65


# ====================================================================================================

# Setting variables for script
# Thread status & commands
tinit = 0
tpilot = 0
tjoy = 0
timu = 0
tpidyaw = 0

#Stop asked
mainloopstop = 0
endpilot = 0
endimu = 0
endjoystick = 0
endpidyaw = 0

# IMU
imu = "init"
s = "init"
pressure = "init"
poll_interval = "init"
imuroll = "init"
imupitch = "init"
imuyaw = "init"
imualt = "init"

# PID yaw
Kpyaw = 1
Kiyaw = 0
Kdyaw = 0

targetyaw = "init"
oldimuyaw = "init"
cdeyaw = "init"
cumerroryaw = 0
olderroryaw = 0

statustype = ""
vartest = 0

oldp1 = "init"
oldp2 = "init"
oldp3 = "init"
oldyaw = "init"

p1 = "init"
p2 = "init"
p3 = "init"
yaw = "init"
ledautopilot = -1

#For global variables
pwm = ""

def percentoduty(percent):
	return min*percent/100+minm

def status():
	global statustype
	statustype = ""
	statustype += "Status :"
	statustype += "\n"
	statustype += "==============================="
	statustype += "\n"
	statustype += "Verbose : "+str(vverbose)
	statustype += "\n"
	statustype += "======"
	statustype += "\n"
	statustype += "UDP_IP :            "+str(UDP_IP)
	statustype += "\n"
	statustype += "UDP_PORT :          "+str(UDP_PORT)
	statustype += "\n"
	statustype += "UDP_PORT_ACK :      "+str(UDP_PORT_ACK)
	statustype += "\n"
	statustype += "UDP_PORT_TELE :     "+str(UDP_PORT_TELE)
	statustype += "\n"
	statustype += "UDP_PORT_JOYSTICK : "+str(UDP_PORT_JOYSTICK)
	statustype += "\n"
	statustype += "======"
	statustype += "\n"
	statustype += "Pin motor 1: "+str(pm1)
	statustype += "\n"
	statustype += "Pin yaw :    "+str(pyaw)
	statustype += "\n"
	statustype += "Pin led :    "+str(pledautopilot)
	statustype += "\n"
	statustype += "======"
	statustype += "\n"
	statustype += "Frequency motor : "+str(freq)
	statustype += "\n"
	statustype += "Minimum motor :   "+str(minm)
	statustype += "\n"
	statustype += "Maximum motor :   "+str(maxm)
	statustype += "\n"
	statustype += "Throttle motor 1 : "+str(p1)
	statustype += "\n"
	statustype += "Throttle motor 2 : "+str(p2)
	statustype += "\n"
	statustype += "Throttle motor 3 : "+str(p3)
	statustype += "\n"
	statustype += "======"
	statustype += "\n"
	statustype += "Flight mode : "+str(flightmode)
	statustype += "\n"
	statustype += "Stat mode :   "+str(statmode)
	statustype += "\n"
	statustype += "Alti mode :   "+str(altimode)
	statustype += "\n"
	statustype += "======"
	statustype += "\n"
	statustype += "Script initialized : "+str(tinit)
	statustype += "\n"
	statustype += "Status pilot : "+str(tpilot)
	statustype += "\n"
	statustype += "Stop pilot asked : "+str(endpilot)
	statustype += "\n"
	statustype += "Stop pilot asked : "+str(endpilot)
	statustype += "\n"
	statustype += "Stop script asked : "+str(mainloopstop)
	statustype += "\n"
	statustype += "Stop script asked : "+str(mainloopstop)


def init():
	verbose("=> Initialization")
	global tinit
	
	global minm
	global maxm
	global moym
	
	global pwm
	
	global imu
	global s
	global pressure
	global poll_interval

	# Settings dutycycles
	minm = int(freq*4.096) #1ms : 1/1000/(1/f)*4096
	maxm = int(freq*8.192) #2ms : 2/1000/(1/f)*4096
	moym = int(maxm-minm)

	pwm = PWM(0x40, debug=True)
	pwm.setPWMFreq(freq) 
	#pwm.setPWM(pm1, 0, minm)
	pwm.setPWM(pm2, 0, minm)
	#pwm.setPWM(pm3, 0, minm)
	pwm.setPWM(pyaw, 0, yawinit)

	#---

	SETTINGS_FILE = "RTIMULib"
    
	verbose("Using settings file " + SETTINGS_FILE + ".ini")
	if not os.path.exists(SETTINGS_FILE + ".ini"):
		verbose("Settings file does not exist, will be created")

	s = RTIMU.Settings(SETTINGS_FILE)
	imu = RTIMU.RTIMU(s)
	pressure = RTIMU.RTPressure(s)

	verbose("IMU Name: " + str(imu.IMUName()))
	verbose("Pressure Name: " + str(pressure.pressureName()))

	if (not imu.IMUInit()):
		verbose("IMU Init Failed")
		sys.exit(1)
	else:
		verbose("IMU Init Succeeded")

	if (not pressure.pressureInit()):
		verbose("Pressure sensor Init Failed")
	else:
		verbose("Pressure sensor Init Succeeded")

	poll_interval = imu.IMUGetPollInterval()
	verbose("Recommended Poll Interval: %dmS\n" % poll_interval)
	
	#---
	
	tinit = 1
	verbose("<= Initialized")

def fpidyaw():
	verbose("=> Starting PID yaw")
	global tpidyaw
	tpidyaw = 1
	global cumerroryaw
	global olderroryaw	
	global cdeyaw	
	
	while endpidyaw == 0:
		if targetyaw != "init" and imuyaw != "init" and imuyaw != oldimuyaw:
		
			error = targetyaw - imuyaw
			cumerroryaw += error
			deltaerror = error - olderroryaw
			olderroryaw = error
			cdeyaw = Kpyaw * error + Kiyaw * cumerroryaw + Kdyaw * deltaerror
			oldimuyaw = imuyaw
			time.sleep(0.1)
		else:
			verbose("=> Yaw not calculated")
	
	tpidyaw = 0
	
	verbose("=>PID yaw stopped")

def stop():
	verbose("=> Stopping")
	global tinit
	global pwm
	global timu
	global endimu
	global endjoystick
	
	endjoystick = 1
	sock = socket(AF_INET, SOCK_DGRAM)
	sock.sendto("0.0.0.0", ("127.0.0.1", UDP_PORT_JOYSTICK))
	
	if tinit == 1:
		#pwm.setPWM(pm1, 0, minm)
		pwm.setPWM(pm2, 0, 0)
		#pwm.setPWM(pm3, 0, minm)
		pwm.setPWM(pyaw, 0, yawinit)
	endimu = 1
		
	tinit = 0
	verbose("<= Stopped")

def fjoystick():
	verbose("=> Starting joystick")
	
	global tjoy
	tjoy = 1
	global flightmode
	flightmode = "MAN"
	global p1
	global p2
	global p3
	global oldp1
	global oldp2
	global oldp3
	global oldyaw
	
	count = 1

	while endjoystick == 0:
		joyroll = ""
		joypitch = ""
		joyyaw = ""
		joythrottle = ""
		vjoy, addr = sjoy.recvfrom(1024)
		vjoy = str(vjoy)
		len2 = len(vjoy)-1
		t = 0
		axis = 0
		while t <= len2:
			if vjoy[t] != ".":
				if axis == 0:
					joyroll = joyroll + vjoy[t]
				elif axis == 1:
					joypitch = joypitch + vjoy[t]
				elif axis == 2:
					joyyaw = joyyaw + vjoy[t]
				elif axis == 3:
					joythrottle = joythrottle + vjoy[t]
			else:
				axis = axis + 1
			t = t + 1
		
		joyroll = int(joyroll)
		joypitch = int(joypitch)
		joyyaw = int(joyyaw)
		joythrottle = int(joythrottle)

		joyyaw = yawinit+(joyyaw/50)
		
		# minimum + interval*puissance + axe*sensibilite (remplacer axe par axe*triangulation)
		p1 = minm+((moym*joythrottle/100)+((joyroll)*sensibilite))
		p2 = minm+((moym*joythrottle/100)-((joyroll)*sensibilite))
		p3 = minm+((moym*joythrottle/100)+((joypitch)*sensibilite))

		maxp = [p1,p2,p3]
		maxp = max(maxp)
		if maxp > maxm:
			p1 = p1*maxm/maxp
			p2 = p2*maxm/maxp
			p3 = p3*maxm/maxp
		
		
		p1 = (p1-minm)/*100
		p2 = (p2-minm)/moym*100
		p3 = (p3-minm)/moym*100
		
		p1=int(p1)
		p2=int(p2)
		p3=int(p3)
		
		print vjoy +" P1 : "+str(p1)+", P2 : "+str(p2)+", P3 : "+str(p3)+", Yaw : "+str(yaw)+", Min : "+str(minm)+" , Max : "+str(maxm)+", Throttle : "+str(vthrottle)

		#if vyaw != oldyaw:
			#pwm.setPWM(pyaw, 0, vyaw)
		#if p1 != oldp1:
			#pwm.setPWM(pm1, 0, p1)
		#if p2 != oldp2:
			#pwm.setPWM(pm2, 0, p2)
		#if p3 != oldp3:
			#pwm.setPWM(pm3, 0, p3)
		
		oldp1 = p1
		oldp2 = p2
		oldp3 = p3
		olpyaw = vyaw
		
	tjoy = 0
	verbose("=> Joystick stopped")

def fmotor1():
	verbose("=> Starting m1")
	global p1
	p1 = int(data)
	pwm.setPWM(pm1, 0, p1)
	verbose("<= M1 stopped")

def fmotor2():
	verbose("=> Starting m2")
	global p2
	p2 = int(data)
	pwm.setPWM(pm2, 0, p2)
	verbose("<= M2 stopped")

def fmotor3():
	verbose("=> Starting m3")
	global p3
	p3 = int(data)
	pwm.setPWM(pm3, 0, p3)
	verbose("<= M3 stopped")

def fyaw():
	verbose("=> Starting yaw")
	global data
	data = int(data)
	pwm.setPWM(pyaw, 0, data)
	verbose("<= Yaw stopped")

def fmotors():
	verbose("=> Starting motors")
	global vartest
	vartest = float(vartest)
	print(vartest)
	#vartest = minm+vartest*maxm/100
	#print(vartest)
	
	#m1.ChangeDutyCycle(vartest)
	#m2.ChangeDutyCycle(vartest)
	#m3.ChangeDutyCycle(vartest)
	verbose("<= Motors stopped")

def pilot():
	tpilot = 1
	verbose("=> Starting pilot")

	stop()
	verbose("<= Pilot stopped")
	tpilot = 0
	
	
def fimu():
	verbose("=> Starting IMU")
	global imu
	global timu

	timu = 1
	
	global imuroll
	global imupitch
	global imuyaw
	global imualt
	
	global targetyaw
	

	
	while tinit == 0:
		time.sleep(1)
		
	verbose("=> Starting reading IMU")
	
	def computeHeight(pressure):
		return 44330.8 * (1 - pow(pressure / 1013.25, 0.190263));
	
	while endimu == 0:
		if imu.IMURead():
			data = imu.getIMUData()
			(data["pressureValid"], data["pressure"], data["temperatureValid"], data["temperature"]) = pressure.pressureRead()
			fusionPose = data["fusionPose"]
			#print "Roll : "+str(math.degrees(fusionPose[0]))+", Pitch : "+str(math.degrees(fusionPose[1]))+", Yaw : "+str(math.degrees(fusionPose[2]))+", Pressure : "+str(data["pressure"])+", Height : "+str(computeHeight(data["pressure"]))+", Temperature : "+str(data["temperature"])
			
			imuroll = math.degrees(fusionPose[0])
			imupitch = math.degrees(fusionPose[1])
			imuyaw = math.degrees(fusionPose[2])
			imualt = computeHeight(data["pressure"])
			
			if targetyaw == "init":
				targetyaw = math.degrees(fusionPose[2])
				
	timu = 0
	verbose("=> IMU stopped")
	
if vverbose == 1:
	status()

verbose("=> Starting main loop")

serversock = socket(AF_INET, SOCK_DGRAM)
serversock.bind(("", UDP_PORT))


while mainloopstop == 0:
	data = ""
	
	verbose("Listening on udp port...")
	try :
		code, addr = serversock.recvfrom(1024)
		code = str(code)

		ack = "Acknowledge : "
		
		verbose("Command received : "+code)
		
		code2 = code[0]+code[1]
		code2 = str(code2)
		if len(code) > 2:
			a = 3
			while a <= len(code):
				data=str(data)
				data = data+code[a-1]
				a = a + 1
		code = code2	
		data = str(data)
		
		if code == "00":
			verbose("Requested threads to stop")
			stop()
			if data == "01":
				verbose("Requested main loop to stop")
				mainloopstop = 1

		elif code == "01":
			if tinit == 0:
				autopilot = threading.Thread(group=None, target=init)
				autopilot.start()
				endimu = 0
				thimu = threading.Thread(group=None, target=fimu)
				thimu.start()
				thpidyaw = threading.Thread(group=None, target=fpidyaw)
				thpidyaw.start()
			else:
				ack = "Already initialized"
				
		elif code == "02":
			verbose("Requested pilot to stop")
			endpilot = 1
					
		elif code == "03":
			verbose("Switching Flight mode to : "+data)
			flightmode = data

		elif code == "05":
			verbose("Receiving IP : "+data)
			UDP_IP = data

		elif code == "06":
			endpilot = 0
			if tpilot != 1:
				if init == 1:
					verbose("Requested pilot to start")
					autopilot = threading.Thread(group=None, target=pilot)
					autopilot.start()
				else:
					ack = "Not initialized" 
			else:
				ack = "Already running"
			
		elif code == "07":
				status()
				ack = statustype

		elif code == "08":
				endjoystick = 0
				sjoy = socket(AF_INET, SOCK_DGRAM)
				sjoy.bind(("", UDP_PORT_JOYSTICK))
				thjoy = threading.Thread(group=None, target=fjoystick)
				thjoy.start()
				
		elif code == "09":
			if tjoy == 1:	
				endjoystick = 1
				sock = socket(AF_INET, SOCK_DGRAM)
				sock.sendto("0.0.0.0", ("127.0.0.1", UDP_PORT_JOYSTICK))
			else:
				ack = "Not running"
				
		elif code == "10":
			if tinit == 1:
				verbose("Requested motors to start")
				vartest = "0"+data
				thmotors = threading.Thread(group=None, target=fmotors)
				thmotors.start()
			else:
				ack = "Not initialized" 

		elif code == "11":
				thmotor1 = threading.Thread(group=None, target=fmotor1)
				thmotor1.start()

		elif code == "12":
				thmotor2 = threading.Thread(group=None, target=fmotor2)
				thmotor2.start()

		elif code == "13":
				thmotor3 = threading.Thread(group=None, target=fmotor3)
				thmotor3.start()

		elif code == "14":
				thyaw = threading.Thread(group=None, target=fyaw)
				thyaw.start()

		else:
			ack = "Unknown command"
			
		time.sleep(0.5)
		ack = ack+" "+str(code)+" "+str(data)
		sock = socket(AF_INET, SOCK_DGRAM)
		sock.sendto(ack, (UDP_IP, UDP_PORT_ACK))
	except:
		verbose("******  ERROR  *******")

verbose("<= Main loop stopped")

verbose("<= End of script")

Une fois fini, il fera quelque chose comme le double

YouTube · Message non lu par **Dehas** » mer. 24 déc. 2014 16:58

T'es pas gentil, ce soir c'est le réveillon et j'aurais mal au crane

Vex · Message non lu par **Vex** » mar. 30 déc. 2014 23:47

Salut Ovopack.

Super projet! Je vais suivre avec attention.

Je suis sur du à peu prêt pareil:
- Quadcopter (Frame=Q450 V3)
- BeagleBone
- Turnigy D2836/8 1100KV x4
- Turnigy dlux 20A
- 8x4~10x4.5 Prop
- Batterie Turnigy 2200mAh 3S 30C
- IMU - AltIMU-10 v3
- Communication en TCP/IP (Client Server) pour le moment. Je pense passer ensuite sur du 3DR Radio ou équivalent.
- Client graphique sur mon PC (Python PyQt / Mathplotlib)

Je vais lire ton code Python. A ce que j'ai vu, il n'y a pas de threading, et c'est du scripting. Si j'ai un conseil à froid ce serais de faire des classes (e.g. IMU, Motors, etc.) et de lancer ça en parralèle (threads). Ce sera plus performant je pense.

-Vex-

Ovopack · Message non lu par **Ovopack** » mar. 30 déc. 2014 23:54

Pas de threading? tu rigoles?

Jettes un coup d'oeil dans les imports en ensuite dans les lancements de thread dans la boucle principale, tout en bas.
Les classes ne sont vraiment importante... faire des liaisons de classe amène à chaques fois à des lectures dans la RAM et ralenti le programme.

La version actuelle a quand même bien changée. je le poseterai en même temps que le résumé de mes derniers travaux.

Pour info, les tests de premier vols sont fait, j'ai réglé mes problèmes de régulation PID.

Par contre j'ai eu droit à un crash : au lieu de taper 10580 pour '10' (tout les moteurs) et '580' (580bits/4096bits*frequence), j'ai tapé 105800.
Donc le multi est parti pleine puissance, heureusement qu'il n'y avait rien sur sa route car j'ai senti une puissance ENORME et je me suis quand meme fait une belle peur.

Ovopack · Message non lu par **Ovopack** » mer. 31 déc. 2014 00:03

J'ai prévu aussi de faire un sorte d'organigramme qui montre visuellement tous les threads (avec ce dont ils ont besoin (de quelle variable), sur quoi ils agissents, etc...), la boucle principale, les actionneurs, les capteurs, ... bref tout ce qui compose le programme.

Malheureusement, l'organisation change tellement qu'il serait plus facile de faire le programme et ensuite faire l'organigramme... Mais j'ai quand meme en tête une assez bonne vision d'ensemble de son fonctionnement donc pour moi faire sans n'est pas un vrai problème.

Quelques rivets à remettre par ci, par là, vérifier les angles, check que tout fonctionne bien, revoir le programme avec une bride logiciel cette fois-ci, l'optimiser (oui parce que pour le moment, j'en suis au test, l'optimisation en profondeur sera fait au dernier moment. Pour le moment, pas besoin d'avoir la vitesse de calcul la plus grande, même si elle est déjà élevée.)

Vex · Message non lu par **Vex** » mer. 31 déc. 2014 00:07

J'ai lu un peu trop vite et partiellement

Pour les classes et l'utilisation de le RAM, je suis curieux de voir à quel point ça peut ralentir le programme. Je ferais des tests. En tout cas c'est plus lisible et maintenable pour ma part.

Au niveau du PID tu utilise quoi ? Angle & Rate (i.e. 5 PIDs) ? Ton IMU est filtré ?

Mon premier multirotor avec raspberry

Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry

Re: Mon premier multirotor avec raspberry