Author Topic: Capsule en dur pour NASSP 7.0 !!!! (Read 103282 times)

Pappy2 · Reply #150 - 21 August 2017, 19:02:30

Alors allez ne perdez pas de temps....

AU BOULOT

Super projet en tout cas

antoo · Reply #151 - 22 August 2017, 01:25:28

Bonsoir!

Le Low Equipement Bay est terminé (enfin, en 3D bien sûr

) !

Il y a plus de 40 pièces, en bois, métal ou plastique. Certains panels sont "déboîtables", afin de les mettre sur les genoux (bah oui, sinon on ne peut pas y accéder... ils sont sous les pieds!)

Vue d'ensemble :

De dessus :

De dessous :

Bonne nuit

antoo · Reply #152 - 24 August 2017, 12:25:39

L'EMS est en cours d'assemblage...

A+

jacquesmomo · Reply #153 - 24 August 2017, 17:39:35

Quel boulot... impressionné je suis !!!

Gingin · Reply #154 - 24 August 2017, 22:56:53

Une vraie petite entreprise, courage

antoo · Reply #155 - 24 August 2017, 23:34:05

Bonsoir messieurs!
Merci pour vos commentaires.

Quelques images du travail fourni aujourd'hui :

Il reste encore pas mal de taf, mais c'est plutôt gratifiant, comme résultat

.
D'ici quelques jours, nous aurons un EMS complet. Il ne sera pas encore, cependant, prêt à recevoir les information d'NASSP. Sur cet aspect là, il y a encore probablement un peu de délai... mais'z'on y travaille

.

A+

maxoo · Reply #156 - 25 January 2018, 23:10:14

Salut tout le monde !
Bon on s'y remet un peu.
J'ai testé l'extraction des variables en recompilant ShuttlePB (on l'aime celui-là !) avec quelques petites fonctions sympa et ça marche super bien. Reste plus qu'à appliquer ça à NASSP !

Sacrée épreuve à compiler, NASSP, de quoi y laisser les dents...
En choisissant un peu au pif, j'ai décidé de compiler Saturn5NASP du projet NASSP (et PanelSDK.lib qui est nécessaire à son fonctionnement). Passées quelques minutes/heures à paramétrer VS2017 (dossiers de libs, includes, ajout des lib au projet, correction de OrbiterSound35 vers OrbiterSound40) la compilation fonctionne, et pouf une DLL toute neuve dans Modules !
Et KRAK Orbiter.exe qui plante...
En décortiquant la DLL grâce à dllexp.exe, on s'aperçoit lors du listage des méthodes externes que ma DLL ne comporte que les fonctions "OvcInit" et "OvcExit"... Alors que la DLL originelle les a, plus une bonne vingtaine de fonctions style "CameraMode::trucmachin" ou encore "MFD::unautreencore".

Je pense que les fonctions sont bien compilées, mais que l'exportation ne se fait pas correctement... Quelqu'un a une intuition ?

On avance on avance...

SCEtoAUX · Reply #157 - 29 May 2018, 23:20:09

Alors, ça avance ce projet ?

Gingin · Reply #158 - 19 June 2018, 17:01:18

On veut des news, fais nous rever

antoo · Reply #159 - 19 June 2018, 20:40:19

Bonsoir les amis!

Notre prototype est construit. Le seul souci? Voir le message de Maxoo ci-dessus

!
En gros, nous sommes face à une impasse de programmation... Le prototype est imprimé, les swich sont assemblés et les cartes sont faites. On est un peu dans la m**de pour tout dire, on a besoin de l'aide d'un programmeur, nous ne parvenons pas à comminiquer avec Orbiter via notre microcontrôleur.

Donc... HELP !
Il suffit juste de ça, et on lance la levée de fonds.

A+

antoo · Reply #160 - 19 June 2018, 20:42:33

Ah horreur... Les photos ont toutes disparues! Je mettrai ça à jour vite fait.

Gingin · Reply #161 - 26 June 2018, 21:19:58

Niquel merci et courage

antoo · Reply #162 - 23 July 2018, 23:15:53

De succulentes et excitantes nouvelles... bientôt

.

A+

jacquesmomo · Reply #163 - 23 July 2018, 23:39:31

antoo · Reply #164 - 25 July 2018, 14:40:06

Nous avons réussi à faire communiquer un microcontrôleur par USB avec NASSP

.
Nous sommes en train de concevoir les cartes electroniques restantes, que Maxoo va réaliser à son travail, avec composants cms (très petits) et microcontrôleur de meilleure qualité (pas arduino quoi...) doté d'un programateur plus puissant.

Pour rappel, nous avons réalisé :
- Le modèle imprimé en 3D de l'EMS
- L'intégration de l'électronique de surface
- La programation (presque terminée) du dialogie via USB
Bref : le prototype est presque fini, on prévoit de vous le montrer en fonctionnement optimal avant la fin du moi d'Août, date à laquelle Maxoo part un an en Chine pour ses études d'ingénieur.

De mon côté, je continue la modélisation en 3D de toutes les pièces du cockpit, je n'en vois pas le bout, c'est TRES LONG

...
J'ai changé de logiciel, je suis sur un logiciel de CAO très puissant, donc ça va être bien pro. Avec cartouche sur plan.
Le truc c'est que Sketchup c'est bien gentil, mais tout est long et fastidieux, et en plus il ne sort pas de plans. Disons que ça m'a permis de me lancer, et d'appréhender les termes et concepts de base de la modélisation.

Nous nous sommes assagis, et avons réellement essayé de nous poser et réfléchir aux contraintes que pourraient rencontrer un fabriquant à qui on commanderait, par exemplen des pièces en bois. Ainsi, j'ai divisé se socle en plusieurs sous-pièces, et je réfléchis à une structure sous-jacente qui nous offre l'inclinaison voulue tout en soutenant les pièces, mais en n'obstruant pas les espaces réservés aux panels du Low Equipement Bay, qui seront des "tiroirs" libres, afin de se les porter sur les genoux au besoin.

Je termine en remettant des photos qui se sont enlevées des posts précédents (merci Hosting Pics

).

EMS

Premières esquisses avec Sketchup

Maxoo au travail

!

D'autres nouvelles très bientôt les gars. Déjà de très très nombreuses heures de travail que l'on ne compte pas. Enivrant !
A+

Snax · Reply #165 - 25 July 2018, 15:04:04

Vraiment très sympa les gars !
Ca change des simpits que j'ai l'habitude de voir dans la simu aéro ^^

Pappy2 · Reply #166 - 25 July 2018, 17:49:11

SUPER

COURAGE POUR LA SUITE

antoo · Reply #167 - 25 July 2018, 17:57:22

Socle en cours. C'est donc une structure en bois, un peu dans un style coque de bateau. Les pièces s'imbriquent entre elles. Il faut laisser la place pour les blocs des panels et les fils. Donc on fait des trous...

.

Pour vous donner une idée, les deux triangles font un peu plus de 2m. C'est grand !

L'outil de CAO est une bénédiction, je peux construire des pièces les unes à partir des autres, puis si j'en modifie une précédament faite, les contraintes sont calculées sur les autres. C'est... bluffant.
Je peux ensuite les assembler et les tester (résistance, cassure, masse, ...).

A+

jacquesmomo · Reply #168 - 25 July 2018, 19:01:17

Quote from: antoo on 25 July 2018, 14:40:06

Je termine en remettant des photos qui se sont enlevées des posts précédents (merci Hosting Pics ).

Essaye là, ça marche bien...
https://www.zupimages.net/

Quote from: antoo on 25 July 2018, 14:40:06

D'autres nouvelles très bientôt les gars. Déjà de très très nombreuses heures de travail que l'on ne compte pas. Enivrant !A+

Dis donc... je ne me souviens plus...
Le tout début de ce projet, c'était quand déjà ???

antoo · Reply #169 - 25 July 2018, 21:32:42

Le début sérieux, c'était grosso modo en 2016

.

Merci pour le lien, j'essaie ça !
A+

maxoo · Reply #170 - 25 July 2018, 22:23:49

Salut les Orbinautes !
Je complète le message d'Antoo par quelques petites infos techniques sur le code et l'électronique

Donc ce qui marche dès maintenant :

La source de NASSP compile et le tout s'exécute (2 ans pour y arriver !!! faute de trouver le bon sourceforge...)
Les modifications apportées à la source saturn.cpp permettent de communiquer en USB CDC avec un µC
Tous les boutons sont pilotés par le µC via l'USB, et au sein de la méthode Staurn::clbkPostStep(...)
Dans cette même fonction, on exporte les données des afficheurs de l'EMS vers un fichier texte (pour l'instant)

Actuellement les données issues des afficheurs sont imprimées dans un .txt pour le débug, mais très vite ce sera envoyé par USB CDC à la carte µC pour imprimer sur les afficheurs.

Ce qui est beau, c'est qu'aucun compromis n'a été fait ici. Après validation de l'EMS, pas de barrière -a priori- particulière à lever sur l'exploitation des switch et l'extraction des donnés µC. Pour ce qui est de l'EMS, ben le code n'a plus beaucoup à évoluer !

Un petit bout de code pour vous :

Code: [Select]

int numButton, newState;
	if (NASSPC_getButtonState(&numButton, &newState))
	{
		if (numButton == 0)
		{
			EMSFunctionSwitch.SetState(newState);
		}
		if (numButton == 1)
		{
			EMSModeSwitch.SetState(newState);
		}
		if (numButton == 2)
		{
			GTASwitch.Unguard();
			GTASwitch.SetState(newState);
		}
		if (numButton == 3)
		{
			int event;
			int clicked_x = 10;
			int clicked_y;
			switch (newState)
			{
				case 0:
					event = PANEL_MOUSE_RBUP;
					break;
				case 1:
					event = PANEL_MOUSE_LBPRESSED;
					clicked_y = 25;
				case 2:
					event = PANEL_MOUSE_RBPRESSED;
					clicked_y = 25;
				case 3:
					event = PANEL_MOUSE_LBPRESSED;
					clicked_y = 50;
				case 4:
					event = PANEL_MOUSE_RBPRESSED;
					clicked_y = 50;
			}
			EMSDvSetSwitch.CheckMouseClick(event, clicked_x, clicked_y);
		}
	}
	//écriture des données en sortie dans un fichier texte
	std::ofstream out_fHandle;
	out_fHandle.open("NASSPC_OUT.txt", std::ios::app);
	// DeltaV
	out_fHandle << "EMS Dv Display : " << EMSDvDisplay.GetState() << endl; // à diviser par 10
	// Scroller. Et le bug ???
	out_fHandle << "EMS Scroll Display : " <<  ems.GetScrollOffset()+EMSScrollDisplay.GetState()-65 << endl;	// en pixels
	out_fHandle << "SPS Thrust light : " << ems.SPSThrustLight() << endl; // led droite
	out_fHandle << ".05G light : " << ems.pt05GLight() << endl;			  // led gauche
	//Truc en bas à gauche
	out_fHandle << "EMS RSI Rotation : " << ems.GetRSIRotation() << endl; // radians
	out_fHandle << "EMS Lift Vect Light : " << ems.LiftVectLight() << endl;	// -1, 0, 1 // -1 est la led du bas, 1 celle du haut
	out_fHandle.close();

A la relecture il apparaît qu'un petit switch/case ne ferait pas de mal. Il devait être 2h du mat...

Et d'un autre côté, pour l'USB CDC :

Code: [Select]

bool NASSPC_getButtonState(int *numButton, int *newState)
{
	CSerial serial;
	if (serial.Open(6, 9600))
	{
		char* lpBuffer = new char[5];
		int nBytesRead = serial.ReadData(lpBuffer, 5);
		serial.Close();
		if ((nBytesRead > 0) && (lpBuffer[0] == '<'))
		{
			*numButton = (int)lpBuffer[1];
			*newState = (int)lpBuffer[3];
#ifdef MAX_DEBUG_MODE
			out.open("NASSPC_log.txt", std::ios::app);
			out << "serial received : " << *numButton << ";" << *newState << endl;
			out.close();
#endif
			delete[]lpBuffer;
			return true;
		}
	}
	return false;
}

Un grand merci à ceux qui ont écrit la classe CSerial, j'ai trouvé ça en 2mn sur google et je ne leur ai pas encore donné crédit. C'est tellement plus sympa que l'API windows...

Pour les cartes électroniques, je vais les refaire sur des PCBs pros (tout vert, double face et avec petites écritures dessus <3) dès que je me trouve une soirée au bureau. Ca va être magnifique!

Merci à tous de nous suivre, ça fait vraiment plaisir. A très vite avec des nouvelles !

Snax · Reply #171 - 26 July 2018, 11:27:44

Si ça peut aider aussi pour les images, le site à la mode maintenant qui ne déçoit pas c'est http://www.imgur.com.
En haut à gauche tu cliques le bouton vert "new post" ou "upload" et tu glisses toutes tes photos dedans en un coup et le site s'occupe de tous les uploader (parfois ils arrivent dans le désordre).

antoo · Reply #172 - 26 July 2018, 16:48:16

Merci Snax, j'ai l'embarras du choix

!

Petite avancée d'aujourd'hui : j'ai refait un rotatif bien fidèle à la réalité, avec angles arrondis et les guides de serrage des vis. C'est à imprimer en 3D bien sûr... en 36 exemplaires haha.

Rassurez vous, je ne vais pas poster une photo de chaque bouton... ...ou pas

!
A+

Maxorbiter · Reply #173 - 26 July 2018, 17:16:06

Vos modèles 3D sont vraiment bien fait !

Sinon perso pour les images je fait juste les poster sur discord et je recup le lien et je les postent ici. C'est super rapide et facile à faire

antoo · Reply #174 - 27 July 2018, 01:18:24

Bonsoir,

Merci Max

.

Travaux réalisés cette après midi. J'ai modélisé la "tête" des switch. Il faudra que l'on les imprime coupés en deux et avec la forme du switch moulée dans le modèle... je sais pas si je suis clair...
Voyez plutôt :

Nous modélisons la forme creuse selon le switch choisi...

Enfin, j'ai réalisé ce... truc ... Levier de pression, panel 2 ! Pourquoi lui? ben en flânant dans le cocpit je me suis dit que cette pièce me formerait, me donnerait un peu de challenge. Faut dire qu'en effet, j'ai galéré un poil ^^ . Il y a bien évidement l'espace pour une vraie vis à loger. Mais l'axe est moulé aussi, car il "rentrera" dans le panel pour se fixer à un gros bouton. J'y retoucherai don le moment venu.

Le vrai :

Bonne nuit

.