Le Logiciel
Etude de faisabilité
Après avoir eu l'idée, je me suis demandé si je disposais des connaissances nécessaires pour tout développer et si cela me semblait réalisable dans un délai correct, tenant compte du fait que je travaille à temps complet pour gagner ma vie. Tout cela dans une optique "produit" qui pourraît être exploitable commercialement si jamais j'en arrivais là.
Coté logiciel, je savais que j'en étais largement capable, par contre coté hardware il fallait étudier la question plus profondément. C'est ainsi que suite à plusieurs tests sur des cartes d'acquisition du marché, je me suis rendu compte que le plus difficile serait la calibration, mais pas le développement.
C'est alors que la réalisation d'un prototype est apparue comme tout à fait réalisable.
Après avoir eu l'idée, je me suis demandé si je disposais des connaissances nécessaires pour tout développer et si cela me semblait réalisable dans un délai correct, tenant compte du fait que je travaille à temps complet pour gagner ma vie. Tout cela dans une optique "produit" qui pourraît être exploitable commercialement si jamais j'en arrivais là.
Coté logiciel, je savais que j'en étais largement capable, par contre coté hardware il fallait étudier la question plus profondément. C'est ainsi que suite à plusieurs tests sur des cartes d'acquisition du marché, je me suis rendu compte que le plus difficile serait la calibration, mais pas le développement.
C'est alors que la réalisation d'un prototype est apparue comme tout à fait réalisable.
Développement logiciel
Suite à cette étude de faisabilité, je me suis lancé durant l'été 2006 dans le codage du moteur d'affichage principal ainsi que la gestion des données à afficher. J'en ai tiré un simulateur d'entrées ainsi qu'un moteur de calcul et d'affichage basique mais qui couvrait déjà l'essentiel : le coté skinnable et une dépendance des données d'entrée permettant de gérer les différences entre divers modèles de voitures.
Ce logiciel est développé sous Windows XP, en utilisant uniquement OpenGL. Ceci dans le but de pouvoir le porter à Linux un jour, si un besoin de commercialisation venait à apparaître, car les licences Linux sont moins chères que les licences Microsoft.
Et voilà une capture d'écran de ce que j'ai obtenu :
Comme vous pouvez le constater il s'agit d'un look qui semble un peu "retro". En fait il s'agit d'une copie du look des tableaux de bord des Renault Super 5. La raison en est très simple, il s'agit de la voiture où sera testé le premier prototype.
Suite à cette étude de faisabilité, je me suis lancé durant l'été 2006 dans le codage du moteur d'affichage principal ainsi que la gestion des données à afficher. J'en ai tiré un simulateur d'entrées ainsi qu'un moteur de calcul et d'affichage basique mais qui couvrait déjà l'essentiel : le coté skinnable et une dépendance des données d'entrée permettant de gérer les différences entre divers modèles de voitures.
Ce logiciel est développé sous Windows XP, en utilisant uniquement OpenGL. Ceci dans le but de pouvoir le porter à Linux un jour, si un besoin de commercialisation venait à apparaître, car les licences Linux sont moins chères que les licences Microsoft.
Et voilà une capture d'écran de ce que j'ai obtenu :
Comme vous pouvez le constater il s'agit d'un look qui semble un peu "retro". En fait il s'agit d'une copie du look des tableaux de bord des Renault Super 5. La raison en est très simple, il s'agit de la voiture où sera testé le premier prototype.
Pourquoi utiliser une aussi vieille voiture comme plate-forme de test & développement ?
1. C'est ma voiture, je l'aime bien et même si j'avais les moyens de m'en acheter une plus récente, je préfère la garder car je sais que je peux la réparer (j'aime beaucoup la mécanique et réparer ma voiture moi même). De plus elle est robuste, très fiable et personne ne veut me la voler. Enfin, elle n'attire pas l'attention et je ne me fais jamais arrêter !
2. Le défi était d'autant plus grand que les données à afficher proviennent de capteurs analogiques ou à se fabriquer soi même. Contrairement aux voitures modernes où ces données sont "servies sur un plateau" (qui s'appelle le bus CAN).
3. Personnellement, mais cela n'engage que moi, j'aime le coté "high-tech retro" : le matériel de James Bond 2028 dans une voiture démodée crée un contraste, sorte de "hight-tech camouflage", qui me plaît particulièrement.
4. Enfin, cela ne faisait pas partie de mon budget de développement que d'acquérir une nouvelle voiture...
1. C'est ma voiture, je l'aime bien et même si j'avais les moyens de m'en acheter une plus récente, je préfère la garder car je sais que je peux la réparer (j'aime beaucoup la mécanique et réparer ma voiture moi même). De plus elle est robuste, très fiable et personne ne veut me la voler. Enfin, elle n'attire pas l'attention et je ne me fais jamais arrêter !
2. Le défi était d'autant plus grand que les données à afficher proviennent de capteurs analogiques ou à se fabriquer soi même. Contrairement aux voitures modernes où ces données sont "servies sur un plateau" (qui s'appelle le bus CAN).
3. Personnellement, mais cela n'engage que moi, j'aime le coté "high-tech retro" : le matériel de James Bond 2028 dans une voiture démodée crée un contraste, sorte de "hight-tech camouflage", qui me plaît particulièrement.
4. Enfin, cela ne faisait pas partie de mon budget de développement que d'acquérir une nouvelle voiture...
Pourquoi Windows XP ?
Tout simplement parce que pour développer rapidement c'était le meilleur choix : je le connais mieux et les drivers des cartes d'acquisition que j'avais testées ne sont malheureusement pas disponibles pour Linux.
Ceci dit, le developpement a été effectué dans l'optique de pouvoir le porter vers Linux ou tout autre OS temps réel plus spécifique, si le besoin se manifeste un jour.
Tout simplement parce que pour développer rapidement c'était le meilleur choix : je le connais mieux et les drivers des cartes d'acquisition que j'avais testées ne sont malheureusement pas disponibles pour Linux.
Ceci dit, le developpement a été effectué dans l'optique de pouvoir le porter vers Linux ou tout autre OS temps réel plus spécifique, si le besoin se manifeste un jour.
D'autres skins ?
Oui, c'est tout à fait faisable, mais pour le moment je me consacre aux fonctionnalités de base que je veux fournir à ce logiciel. Même si cela ne me coûterait pas beaucoup, mon temps est précieux et les developpements longs. Mais ca viendra...
Oui, c'est tout à fait faisable, mais pour le moment je me consacre aux fonctionnalités de base que je veux fournir à ce logiciel. Même si cela ne me coûterait pas beaucoup, mon temps est précieux et les developpements longs. Mais ca viendra...
L'adapter à un bus CAN (ODB-II) ?
Qui peut le plus peut le moins : il suffirait de remplacer le module de calcul par un module d'acquisition CAN et le tour est joué, sans modifier le reste du logiciel. Si ce n'est pas fait actuellement c'est seulement faute de temps et de moyens de test.
Qui peut le plus peut le moins : il suffirait de remplacer le module de calcul par un module d'acquisition CAN et le tour est joué, sans modifier le reste du logiciel. Si ce n'est pas fait actuellement c'est seulement faute de temps et de moyens de test.
Resumé des caractéristiques
- Module de calcul des données en provenances des capteurs (analyse, filtrage, lissage, etc...) ;
- Module d'affichage permettant d'afficher des jauges radiales, voyants, compteurs animés et d'afficher du texte;
- Module de gestion des skins (apparences graphiques)
Langage : C++
Graphique : OpenGL
Système d'exploitation : Windows XP
Architecture : Temps réel embarquable : aucune allocation dynamique (facilement adaptable à une architecture statique), pas de threads, code documenté Doxygen, etc...
Performances : 70-100Hz (fréquence de rafraichissement des données ET de l'affichage écran, en d'autres termes, la durée d'un cycle complet est de 10 à 15ms).
- Module de calcul des données en provenances des capteurs (analyse, filtrage, lissage, etc...) ;
- Module d'affichage permettant d'afficher des jauges radiales, voyants, compteurs animés et d'afficher du texte;
- Module de gestion des skins (apparences graphiques)
Langage : C++
Graphique : OpenGL
Système d'exploitation : Windows XP
Architecture : Temps réel embarquable : aucune allocation dynamique (facilement adaptable à une architecture statique), pas de threads, code documenté Doxygen, etc...
Performances : 70-100Hz (fréquence de rafraichissement des données ET de l'affichage écran, en d'autres termes, la durée d'un cycle complet est de 10 à 15ms).
Historique
Eté 2006
Je consacre mes vacances d'été à developper un logiciel skinnable permettant de calculer et d'afficher les données indispensables dans un tableau de bord.
Octobre 2005
L'idée apparaît. Durant un long trajet pendant que je roulais sur une route droite et ennuyeuse.
Eté 2006
Je consacre mes vacances d'été à developper un logiciel skinnable permettant de calculer et d'afficher les données indispensables dans un tableau de bord.
Octobre 2005
L'idée apparaît. Durant un long trajet pendant que je roulais sur une route droite et ennuyeuse.