Du C ou du Java dans les systèmes embarqués automobile ?
246 réponses
Zeldus
Bonjour,
Les voitures faisant de plus en plus appel à l'électronique pour
fonctionner, même pour les tâches les plus basiques, en quel langage sont
programmés les applications qui gèrent les différentes fonctions
électroniques intégrés aux voitures ?
J'ai pensé à l'assembleur mais vu la aujourd'hui puissance et le prix des
processeurs même les plus basiques, je pense que ce n'est pas le cas et la
tâche serait complexe pour les programmeurs.
Vient ensuite le C, celui qui serait probablement le plus adapté, ancien
mais toujours très efficace ou alors Java, complètement portable mais qui
nécessite une machine virtuelle assez lourde.
Il est beaucoup trop cher pour un telephone, et en plus il bouffe trop de batterie ?
Ah, et puis il prend 3 minutes a rebooter...
Sylvain SF
Zeldus a écrit :
En même temps, tous les éditeurs d'applis mobiles téléphones / smartphones / PDA (essentiellement les jeux mais pas seulement) sont bien contents d'avoir JavaME à leur disposition car avec plus de 1000 modèles de téléphones dispo utilisant des processeurs différents, une quantité de RAM différente, une résolution d'écran différente et j'en passe, il y aurait de quoi s'arracher les cheveux.
je nuancerais, si pour un constructeur il est difficile de gérer 1000 terminaux, mémoire, écran, etc, il serait bien inspirer de commencer par faire moins de modèles. dans la réalité, ils en font effectivement moins et ne gèrent que qlq plate-formes matérielles.
Aujourd'hui, ce qui permet de distribuler le même code écrit pour un Sony Ericsson sur un Nokia ou un Motorola, c'est bien Java, sachant qu'on trouve un peu de tout dans les processeurs embarqués dans les terminaux mobiles.
pour autant (que ces plate-formes soient réduites) ce n'est pas au niveau Java (sauf exception) que ces différences sont supportées. la distribution de codes dont tu parles ici ne concerne que la VM (micro-édition) contenue dans la puce et non dans le mobile. (les applis disposent d'une API SIM-toolkit qui permet de pousser un message sur l'écran ou autres actions basiques, mais elles ne communiquent pas avec tous les moyens hard du mobile).
reste que le marché (des fabriquants de mobiles) change et qu'ils se passeraient bien de la puce - pour gagner en services à valeur ajoutée, tels paiement et autre c*n*e*i*s à la mode. on pourrait donc imaginer une plate-forme mobile réellement ouverte supportant une édition non trop restreinte) de Java.
Sylvain.
Zeldus a écrit :
En même temps, tous les éditeurs d'applis mobiles téléphones /
smartphones / PDA (essentiellement les jeux mais pas seulement) sont
bien contents d'avoir JavaME à leur disposition car avec plus de 1000
modèles de téléphones dispo utilisant des processeurs différents, une
quantité de RAM différente, une résolution d'écran différente et j'en
passe, il y aurait de quoi s'arracher les cheveux.
je nuancerais, si pour un constructeur il est difficile de gérer
1000 terminaux, mémoire, écran, etc, il serait bien inspirer de
commencer par faire moins de modèles.
dans la réalité, ils en font effectivement moins et ne gèrent que
qlq plate-formes matérielles.
Aujourd'hui, ce qui
permet de distribuler le même code écrit pour un Sony Ericsson sur un
Nokia ou un Motorola, c'est bien Java, sachant qu'on trouve un peu de
tout dans les processeurs embarqués dans les terminaux mobiles.
pour autant (que ces plate-formes soient réduites) ce n'est pas au
niveau Java (sauf exception) que ces différences sont supportées.
la distribution de codes dont tu parles ici ne concerne que la
VM (micro-édition) contenue dans la puce et non dans le mobile.
(les applis disposent d'une API SIM-toolkit qui permet de pousser
un message sur l'écran ou autres actions basiques, mais elles ne
communiquent pas avec tous les moyens hard du mobile).
reste que le marché (des fabriquants de mobiles) change et qu'ils
se passeraient bien de la puce - pour gagner en services à valeur
ajoutée, tels paiement et autre c*n*e*i*s à la mode.
on pourrait donc imaginer une plate-forme mobile réellement ouverte
supportant une édition non trop restreinte) de Java.
En même temps, tous les éditeurs d'applis mobiles téléphones / smartphones / PDA (essentiellement les jeux mais pas seulement) sont bien contents d'avoir JavaME à leur disposition car avec plus de 1000 modèles de téléphones dispo utilisant des processeurs différents, une quantité de RAM différente, une résolution d'écran différente et j'en passe, il y aurait de quoi s'arracher les cheveux.
je nuancerais, si pour un constructeur il est difficile de gérer 1000 terminaux, mémoire, écran, etc, il serait bien inspirer de commencer par faire moins de modèles. dans la réalité, ils en font effectivement moins et ne gèrent que qlq plate-formes matérielles.
Aujourd'hui, ce qui permet de distribuler le même code écrit pour un Sony Ericsson sur un Nokia ou un Motorola, c'est bien Java, sachant qu'on trouve un peu de tout dans les processeurs embarqués dans les terminaux mobiles.
pour autant (que ces plate-formes soient réduites) ce n'est pas au niveau Java (sauf exception) que ces différences sont supportées. la distribution de codes dont tu parles ici ne concerne que la VM (micro-édition) contenue dans la puce et non dans le mobile. (les applis disposent d'une API SIM-toolkit qui permet de pousser un message sur l'écran ou autres actions basiques, mais elles ne communiquent pas avec tous les moyens hard du mobile).
reste que le marché (des fabriquants de mobiles) change et qu'ils se passeraient bien de la puce - pour gagner en services à valeur ajoutée, tels paiement et autre c*n*e*i*s à la mode. on pourrait donc imaginer une plate-forme mobile réellement ouverte supportant une édition non trop restreinte) de Java.
Le système d'exploitation qui pilote le Mars Rover est écrit en C++. Le logiciel de capture et traitement d'images du Mars Rover est du C++.
Ouh là là, vous m'étonnez. Ou alors ce que vous écrivez est complémentaire avec ce que je crois savoir. Le problème de Mars Rover est la durée de la boucle d'échange, ajoutée aux périodes de masquage radio, qui interdisent tout fonctionnement interactif. Le robot devait donc être autonome. Sa durée de vie étant soumise à de gros doutes, il devait très rapidement être en mesure de décider ce qui pouvait être *important* et le faire en priorité. En fait comme un humain bien constitué, il devait être en mesure de *distinguer l'essentiel de l'accessoire*. Il fut donc développé, en Scheme me semble-t-il, un module révolutionnaire d'IA. Le résultat par rapport au cahier des charges - distinguer l'essentiel de l'accessoire - fut au-delà de toutes les espérances. Le 3 janvier 2004, le premier rover, MER-A, se posa sur Mars. Il s'en suivit un période de grande inquiétude, puisqu'il resta muet pendant plus de trente-six heurs. Enfin arriva son premier message, qui devait rester le dernier, puisqu'il disait tout: "It' beautiful!"
-- Pierre Maurette
Gabriel Dos Reis, le 03/07/2009 a écrit :
[...]
Le système d'exploitation qui pilote le Mars Rover est écrit en C++.
Le logiciel de capture et traitement d'images du Mars Rover est du C++.
Ouh là là, vous m'étonnez. Ou alors ce que vous écrivez est
complémentaire avec ce que je crois savoir. Le problème de Mars Rover
est la durée de la boucle d'échange, ajoutée aux périodes de masquage
radio, qui interdisent tout fonctionnement interactif. Le robot devait
donc être autonome. Sa durée de vie étant soumise à de gros doutes, il
devait très rapidement être en mesure de décider ce qui pouvait être
*important* et le faire en priorité. En fait comme un humain bien
constitué, il devait être en mesure de *distinguer l'essentiel de
l'accessoire*.
Il fut donc développé, en Scheme me semble-t-il, un module
révolutionnaire d'IA. Le résultat par rapport au cahier des charges -
distinguer l'essentiel de l'accessoire - fut au-delà de toutes les
espérances. Le 3 janvier 2004, le premier rover, MER-A, se posa sur
Mars. Il s'en suivit un période de grande inquiétude, puisqu'il resta
muet pendant plus de trente-six heurs. Enfin arriva son premier
message, qui devait rester le dernier, puisqu'il disait tout:
"It' beautiful!"
Le système d'exploitation qui pilote le Mars Rover est écrit en C++. Le logiciel de capture et traitement d'images du Mars Rover est du C++.
Ouh là là, vous m'étonnez. Ou alors ce que vous écrivez est complémentaire avec ce que je crois savoir. Le problème de Mars Rover est la durée de la boucle d'échange, ajoutée aux périodes de masquage radio, qui interdisent tout fonctionnement interactif. Le robot devait donc être autonome. Sa durée de vie étant soumise à de gros doutes, il devait très rapidement être en mesure de décider ce qui pouvait être *important* et le faire en priorité. En fait comme un humain bien constitué, il devait être en mesure de *distinguer l'essentiel de l'accessoire*. Il fut donc développé, en Scheme me semble-t-il, un module révolutionnaire d'IA. Le résultat par rapport au cahier des charges - distinguer l'essentiel de l'accessoire - fut au-delà de toutes les espérances. Le 3 janvier 2004, le premier rover, MER-A, se posa sur Mars. Il s'en suivit un période de grande inquiétude, puisqu'il resta muet pendant plus de trente-six heurs. Enfin arriva son premier message, qui devait rester le dernier, puisqu'il disait tout: "It' beautiful!"
-- Pierre Maurette
JKB
Le 03-07-2009, ? propos de Re: Du C ou du Java dans les systèmes embarqués automobile ?, Gabriel Dos Reis ?crivait dans fr.comp.lang.c :
JKB writes:
[...]
| > uniquement si on ne sait pas ce c'est le problème. Dans ce cas, c'est | > pas le langage. C'est le programmeur. | | Non. Tu peux dire tout ce que tu veux,
Non seulement je peux dire tout ce que je veux, mais je peux aussi étayer mes allégations.
Ça tombe bien, moi aussi.
| mais lorsque tu écris un | malloc() en C, tu sais exactement ce que tu fais
et comment peux-tu prouver cela ?
Parce que j'ai passé une partie de ma vie sur des codes critiques à qualifier des compilos et à regarder exactement ce qu'ils généraient. Un malloc() en C, c'est un appel à la libc qui alloue de la mémoire. Une allocation d'un objet en C++ ou en Java, c'est un tas de mécanismes imbriqués qui se _terminent_ par un appel du type malloc ou mmap. Je prétends donc que tu _sais_ ce que tu veux faire au niveau de ton objet, mais tu ne _sais_ pas exactement comment le code va le faire. C'est même pour ça qu'on avait l'interdiction d'utiliser autre chose que du C, ADA ou Fortran dans toutes les applications militaires critiques.
| (hors problème | d'implantation du malloc sur l'OS en question). Lorsque tu crées des | objects en C++ ou en Java, tu ne sais plus ce que tu fais _exactement_.
Erreur. Sit *tu* ne sais pas ce que tu fais, alors tu as un problème de compréhension -- ce n'est pas le langage.
J'aimerais rencontrer _une_ seule personne capable de m'expliquer dans le détail tout ce que génère un bout de code C++ et toutes les étapes élémentaires (et la façon qu'a le compilo de les optimiser). Il faut être un minimum sérieux ! Même avec un vulgaire compilo C, les optimisations ne sont pas piquées des vers, alors avec un C++...
| Tu sais exactement ce que tu cherches à faire, mais tu ne sais pas | exactement ce que le compilateur va générer comme code.
Huh? Et comment le sais-tu pour le C ?
Parce qu'il y a nettement moins de couches d'abstraction, avec un peu d'habitude, on arrive a avoir une idée assez précise.
| C'est exactement | pour cela qu'on se retrouve avec des logiciels style usine à gaz qui | utilisent les ressources des machines comme des gorets.
Encore une fois, tu confonds incompétence de programmeur avec outil -- mais je ne suis pas trop surpris, en lisant les lignes auxquelles je réponds.
Non, je ne confonds absolument pas. Mais depuis plus de vingt ans que je pratique, je constate une chose étonnante. Dès que quelqu'un dit que les langages objets ne sont pas _bons_ pour telle ou telle chose, on lui répond toujours qu'il n'a rien compris ou qu'il mélange tout.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 03-07-2009, ? propos de
Re: Du C ou du Java dans les systèmes embarqués automobile ?,
Gabriel Dos Reis ?crivait dans fr.comp.lang.c :
JKB <knatschke@koenigsberg.fr> writes:
[...]
| > uniquement si on ne sait pas ce c'est le problème. Dans ce cas, c'est
| > pas le langage. C'est le programmeur.
|
| Non. Tu peux dire tout ce que tu veux,
Non seulement je peux dire tout ce que je veux, mais je peux aussi
étayer mes allégations.
Ça tombe bien, moi aussi.
| mais lorsque tu écris un
| malloc() en C, tu sais exactement ce que tu fais
et comment peux-tu prouver cela ?
Parce que j'ai passé une partie de ma vie sur des codes critiques à
qualifier des compilos et à regarder exactement ce qu'ils généraient. Un
malloc() en C, c'est un appel à la libc qui alloue de la mémoire. Une
allocation d'un objet en C++ ou en Java, c'est un tas de mécanismes
imbriqués qui se _terminent_ par un appel du type malloc ou mmap. Je
prétends donc que tu _sais_ ce que tu veux faire au niveau de ton objet,
mais tu ne _sais_ pas exactement comment le code va le faire. C'est même
pour ça qu'on avait l'interdiction d'utiliser autre chose que du C, ADA ou
Fortran dans toutes les applications militaires critiques.
| (hors problème
| d'implantation du malloc sur l'OS en question). Lorsque tu crées des
| objects en C++ ou en Java, tu ne sais plus ce que tu fais _exactement_.
Erreur. Sit *tu* ne sais pas ce que tu fais, alors tu as un problème de
compréhension -- ce n'est pas le langage.
J'aimerais rencontrer _une_ seule personne capable de m'expliquer
dans le détail tout ce que génère un bout de code C++ et toutes les
étapes élémentaires (et la façon qu'a le compilo de les optimiser). Il
faut être un minimum sérieux ! Même avec un vulgaire compilo C, les
optimisations ne sont pas piquées des vers, alors avec un C++...
| Tu sais exactement ce que tu cherches à faire, mais tu ne sais pas
| exactement ce que le compilateur va générer comme code.
Huh? Et comment le sais-tu pour le C ?
Parce qu'il y a nettement moins de couches d'abstraction, avec un
peu d'habitude, on arrive a avoir une idée assez précise.
| C'est exactement
| pour cela qu'on se retrouve avec des logiciels style usine à gaz qui
| utilisent les ressources des machines comme des gorets.
Encore une fois, tu confonds incompétence de programmeur avec outil --
mais je ne suis pas trop surpris, en lisant les lignes auxquelles je
réponds.
Non, je ne confonds absolument pas. Mais depuis plus de vingt ans
que je pratique, je constate une chose étonnante. Dès que quelqu'un dit
que les langages objets ne sont pas _bons_ pour telle ou telle chose, on
lui répond toujours qu'il n'a rien compris ou qu'il mélange tout.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 03-07-2009, ? propos de Re: Du C ou du Java dans les systèmes embarqués automobile ?, Gabriel Dos Reis ?crivait dans fr.comp.lang.c :
JKB writes:
[...]
| > uniquement si on ne sait pas ce c'est le problème. Dans ce cas, c'est | > pas le langage. C'est le programmeur. | | Non. Tu peux dire tout ce que tu veux,
Non seulement je peux dire tout ce que je veux, mais je peux aussi étayer mes allégations.
Ça tombe bien, moi aussi.
| mais lorsque tu écris un | malloc() en C, tu sais exactement ce que tu fais
et comment peux-tu prouver cela ?
Parce que j'ai passé une partie de ma vie sur des codes critiques à qualifier des compilos et à regarder exactement ce qu'ils généraient. Un malloc() en C, c'est un appel à la libc qui alloue de la mémoire. Une allocation d'un objet en C++ ou en Java, c'est un tas de mécanismes imbriqués qui se _terminent_ par un appel du type malloc ou mmap. Je prétends donc que tu _sais_ ce que tu veux faire au niveau de ton objet, mais tu ne _sais_ pas exactement comment le code va le faire. C'est même pour ça qu'on avait l'interdiction d'utiliser autre chose que du C, ADA ou Fortran dans toutes les applications militaires critiques.
| (hors problème | d'implantation du malloc sur l'OS en question). Lorsque tu crées des | objects en C++ ou en Java, tu ne sais plus ce que tu fais _exactement_.
Erreur. Sit *tu* ne sais pas ce que tu fais, alors tu as un problème de compréhension -- ce n'est pas le langage.
J'aimerais rencontrer _une_ seule personne capable de m'expliquer dans le détail tout ce que génère un bout de code C++ et toutes les étapes élémentaires (et la façon qu'a le compilo de les optimiser). Il faut être un minimum sérieux ! Même avec un vulgaire compilo C, les optimisations ne sont pas piquées des vers, alors avec un C++...
| Tu sais exactement ce que tu cherches à faire, mais tu ne sais pas | exactement ce que le compilateur va générer comme code.
Huh? Et comment le sais-tu pour le C ?
Parce qu'il y a nettement moins de couches d'abstraction, avec un peu d'habitude, on arrive a avoir une idée assez précise.
| C'est exactement | pour cela qu'on se retrouve avec des logiciels style usine à gaz qui | utilisent les ressources des machines comme des gorets.
Encore une fois, tu confonds incompétence de programmeur avec outil -- mais je ne suis pas trop surpris, en lisant les lignes auxquelles je réponds.
Non, je ne confonds absolument pas. Mais depuis plus de vingt ans que je pratique, je constate une chose étonnante. Dès que quelqu'un dit que les langages objets ne sont pas _bons_ pour telle ou telle chose, on lui répond toujours qu'il n'a rien compris ou qu'il mélange tout.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Zeldus
"Marc Espie" a écrit dans le message de news:h2lrbg$4ek$
Nokia a aussi rachete trolltech, ca n'est pas une coincidence...
Et c'est aussi eux qui fabriquent les meilleurs telephones du marche... (si on veut un telephone, pas un appareil photo/lecteur de film/GPS...)
Je pense aussi que Nokia est le meilleur fabricant de mobiles et de smartphones, essentiellement par leur expérience (c'est un pionnier dans le GSM), et ils utilisent Symbian car à une certaine époque (on va dire avant 2004 MIDP 2.0 pour avoir quelque chose de potable), Java n'existait même pas, ou alors pas dans une forme satisfaisante *sur mobile*.
Maintenant, on a Flash Lite 3, dont Nokia et Sony Ericsson sont les principaux soutiens, qui permet grosso modo d'avoir Flash 8.0 sur un téléphone mobile avec gestion du code actionscript 2, vidéo, musique, etc. Sony Ericsson permet de faire communiquer des midlets Java MIDP 2.0 avec des applis Flash Lite via son interface Capuchin. Microsoft joue lui à fond la carte du C# sur .NET avec Windows Mobile, bien entendu incompatible avec Symbian et autre Java. Mais toutes ces plateformes ont l'avantage de supporter Java MIDP, donc, la quasi totalité des développeurs travaillent avec cette plateforme, délaissant les systèmes proprétaires certes plus performants mais les enfermant chez un constructeur particulier.
Bref, pour un éditeur qui souhaite toucher le maximum d'utilisateurs avec ses produits, la solution viable actuellement, c'est Java. Après, on peut taper dans le haut de gamme avec des applis propriétaires en C++ Symbian, .NET Windows Mobile ou Flash Lite mais c'est largement minoritaire sur le marché.
Pierre
"Marc Espie" <espie@lain.home> a écrit dans le message de
news:h2lrbg$4ek$1@saria.nerim.net...
Nokia a aussi rachete trolltech, ca n'est pas une coincidence...
Et c'est aussi eux qui fabriquent les meilleurs telephones du marche...
(si on veut un telephone, pas un appareil photo/lecteur de film/GPS...)
Je pense aussi que Nokia est le meilleur fabricant de mobiles et de
smartphones, essentiellement par leur expérience (c'est un pionnier dans le
GSM), et ils utilisent Symbian car à une certaine époque (on va dire avant
2004 MIDP 2.0 pour avoir quelque chose de potable), Java n'existait même
pas, ou alors pas dans une forme satisfaisante *sur mobile*.
Maintenant, on a Flash Lite 3, dont Nokia et Sony Ericsson sont les
principaux soutiens, qui permet grosso modo d'avoir Flash 8.0 sur un
téléphone mobile avec gestion du code actionscript 2, vidéo, musique, etc.
Sony Ericsson permet de faire communiquer des midlets Java MIDP 2.0 avec des
applis Flash Lite via son interface Capuchin. Microsoft joue lui à fond la
carte du C# sur .NET avec Windows Mobile, bien entendu incompatible avec
Symbian et autre Java. Mais toutes ces plateformes ont l'avantage de
supporter Java MIDP, donc, la quasi totalité des développeurs travaillent
avec cette plateforme, délaissant les systèmes proprétaires certes plus
performants mais les enfermant chez un constructeur particulier.
Bref, pour un éditeur qui souhaite toucher le maximum d'utilisateurs avec
ses produits, la solution viable actuellement, c'est Java. Après, on peut
taper dans le haut de gamme avec des applis propriétaires en C++ Symbian,
.NET Windows Mobile ou Flash Lite mais c'est largement minoritaire sur le
marché.
"Marc Espie" a écrit dans le message de news:h2lrbg$4ek$
Nokia a aussi rachete trolltech, ca n'est pas une coincidence...
Et c'est aussi eux qui fabriquent les meilleurs telephones du marche... (si on veut un telephone, pas un appareil photo/lecteur de film/GPS...)
Je pense aussi que Nokia est le meilleur fabricant de mobiles et de smartphones, essentiellement par leur expérience (c'est un pionnier dans le GSM), et ils utilisent Symbian car à une certaine époque (on va dire avant 2004 MIDP 2.0 pour avoir quelque chose de potable), Java n'existait même pas, ou alors pas dans une forme satisfaisante *sur mobile*.
Maintenant, on a Flash Lite 3, dont Nokia et Sony Ericsson sont les principaux soutiens, qui permet grosso modo d'avoir Flash 8.0 sur un téléphone mobile avec gestion du code actionscript 2, vidéo, musique, etc. Sony Ericsson permet de faire communiquer des midlets Java MIDP 2.0 avec des applis Flash Lite via son interface Capuchin. Microsoft joue lui à fond la carte du C# sur .NET avec Windows Mobile, bien entendu incompatible avec Symbian et autre Java. Mais toutes ces plateformes ont l'avantage de supporter Java MIDP, donc, la quasi totalité des développeurs travaillent avec cette plateforme, délaissant les systèmes proprétaires certes plus performants mais les enfermant chez un constructeur particulier.
Bref, pour un éditeur qui souhaite toucher le maximum d'utilisateurs avec ses produits, la solution viable actuellement, c'est Java. Après, on peut taper dans le haut de gamme avec des applis propriétaires en C++ Symbian, .NET Windows Mobile ou Flash Lite mais c'est largement minoritaire sur le marché.
Pierre
Hamiral
Pierre Maurette a écrit :
Gabriel Dos Reis, le 03/07/2009 a écrit :
[...]
Le système d'exploitation qui pilote le Mars Rover est écrit en C+ +. Le logiciel de capture et traitement d'images du Mars Rover est du C++ .
Ouh là là, vous m'étonnez. Ou alors ce que vous écrivez est complémentaire avec ce que je crois savoir. Le problème de Mars Rov er est la durée de la boucle d'échange, ajoutée aux périodes de ma squage radio, qui interdisent tout fonctionnement interactif. Le robot devait donc être autonome. Sa durée de vie étant soumise à de gros dou tes, il devait très rapidement être en mesure de décider ce qui pouvait ê tre *important* et le faire en priorité. En fait comme un humain bien constitué, il devait être en mesure de *distinguer l'essentiel de l'accessoire*. Il fut donc développé, en Scheme me semble-t-il, un module révolutionnaire d'IA. Le résultat par rapport au cahier des charges - distinguer l'essentiel de l'accessoire - fut au-delà de toutes les espérances. Le 3 janvier 2004, le premier rover, MER-A, se posa sur Mars. Il s'en suivit un période de grande inquiétude, puisqu'il res ta muet pendant plus de trente-six heurs. Enfin arriva son premier message , qui devait rester le dernier, puisqu'il disait tout: "It' beautiful!"
Excellent :D
Ham
Pierre Maurette a écrit :
Gabriel Dos Reis, le 03/07/2009 a écrit :
[...]
Le système d'exploitation qui pilote le Mars Rover est écrit en C+ +.
Le logiciel de capture et traitement d'images du Mars Rover est du C++ .
Ouh là là, vous m'étonnez. Ou alors ce que vous écrivez est
complémentaire avec ce que je crois savoir. Le problème de Mars Rov er
est la durée de la boucle d'échange, ajoutée aux périodes de ma squage
radio, qui interdisent tout fonctionnement interactif. Le robot devait
donc être autonome. Sa durée de vie étant soumise à de gros dou tes, il
devait très rapidement être en mesure de décider ce qui pouvait ê tre
*important* et le faire en priorité. En fait comme un humain bien
constitué, il devait être en mesure de *distinguer l'essentiel de
l'accessoire*.
Il fut donc développé, en Scheme me semble-t-il, un module
révolutionnaire d'IA. Le résultat par rapport au cahier des charges -
distinguer l'essentiel de l'accessoire - fut au-delà de toutes les
espérances. Le 3 janvier 2004, le premier rover, MER-A, se posa sur
Mars. Il s'en suivit un période de grande inquiétude, puisqu'il res ta
muet pendant plus de trente-six heurs. Enfin arriva son premier message ,
qui devait rester le dernier, puisqu'il disait tout:
"It' beautiful!"
Le système d'exploitation qui pilote le Mars Rover est écrit en C+ +. Le logiciel de capture et traitement d'images du Mars Rover est du C++ .
Ouh là là, vous m'étonnez. Ou alors ce que vous écrivez est complémentaire avec ce que je crois savoir. Le problème de Mars Rov er est la durée de la boucle d'échange, ajoutée aux périodes de ma squage radio, qui interdisent tout fonctionnement interactif. Le robot devait donc être autonome. Sa durée de vie étant soumise à de gros dou tes, il devait très rapidement être en mesure de décider ce qui pouvait ê tre *important* et le faire en priorité. En fait comme un humain bien constitué, il devait être en mesure de *distinguer l'essentiel de l'accessoire*. Il fut donc développé, en Scheme me semble-t-il, un module révolutionnaire d'IA. Le résultat par rapport au cahier des charges - distinguer l'essentiel de l'accessoire - fut au-delà de toutes les espérances. Le 3 janvier 2004, le premier rover, MER-A, se posa sur Mars. Il s'en suivit un période de grande inquiétude, puisqu'il res ta muet pendant plus de trente-six heurs. Enfin arriva son premier message , qui devait rester le dernier, puisqu'il disait tout: "It' beautiful!"
