Bueno, he estado pensando. En este blog estoy hablando de mis experiencias en mi subsistema de XaTcobeo, y he dejado de lado mi blog "personal". En realidad lo que digo aquí es "personal", puesto que hablo de mis cosas, pero mi querido "vigoexiste" de toda la vida se ha quedado de lado.
No merece la pena llevar dos blogs. ¿Sabéis lo que os digo? Que me vuelvo al original que tiene ya un ciento de entradas y listo. Ya sabéis: http://vigoexiste.blogspot.com. Para mí será más fácil no dejarlo desatendido y si a vosotros no os parece interesante ver cómo mezclo cosas del trabajo con mis tonterías con Linux y demás, pues para eso están los comentarios... ¡Que sois muy tímidos!
Agradezco a los que me habéis dicho que os gusta este blog y os invito a mi blog de siempre ;-) Copiaré estas entrada allá. Disculpad las molestias.
Por cierto, agradecería a aquellos que han enlazado este blog que volvieran al enlace original de vigoexiste.blogspot.com :-D
Saludetes a todos :-)
martes, 16 de septiembre de 2008
lunes, 15 de septiembre de 2008
Un gran esfuerzo
Hoy vamos a dejar de lado la SRAD. Como os comenté hace ya un tiempo, el principal objetivo del proyecto XaTcobeo es ser educativo, formar estudiantes, dar becas, proyectos fin de carrera, tesis doctorales, experiencia. Todos estamos aprendiendo. Y no solo eso: como os comenté el día que hablé de nuestra presentación en Utah, el trabajo en equipo, la coordinación, el esfuerzo conjunto era la baza que nos diferenciaba del resto.
En estos momentos, tras dos meses de pronunciado esfuerzo por parte del equipo de Ingeniería de Sistemas (en adelante, cariñosamente, "los de Sistemas") y colaboradores, las principales herramientas de la plataforma de gestión distribuida están a punto. Esto significa que no es extrictamente necesario que trabajemos físicamente juntos, pues podemos estarlo virtualmente. Tenemos un montón de servicios accesibles vía web que nos ofrecen herramientas de trabajo colaborativo. Por ello los del INTA en Madrid y nosotros en Vigo podemos trabajar juntos, revisarnos, charlar... Lógicamente no puedo daros acceso a dichas herramientas, la mayoría son de uso exclusivamente interno (la página web y los foros, una vez aprobados, serán públicos, pero lo demás no), pero somos una suerte de maniacos del software libre, así que os puedo explicar perfectamente de qué estamos hablando:
Esto me recuerda que tengo que redactar la descripción funcional y técnica de la SRAD y meterla en su sitio correspondiente, que la revisen...
En estos momentos, tras dos meses de pronunciado esfuerzo por parte del equipo de Ingeniería de Sistemas (en adelante, cariñosamente, "los de Sistemas") y colaboradores, las principales herramientas de la plataforma de gestión distribuida están a punto. Esto significa que no es extrictamente necesario que trabajemos físicamente juntos, pues podemos estarlo virtualmente. Tenemos un montón de servicios accesibles vía web que nos ofrecen herramientas de trabajo colaborativo. Por ello los del INTA en Madrid y nosotros en Vigo podemos trabajar juntos, revisarnos, charlar... Lógicamente no puedo daros acceso a dichas herramientas, la mayoría son de uso exclusivamente interno (la página web y los foros, una vez aprobados, serán públicos, pero lo demás no), pero somos una suerte de maniacos del software libre, así que os puedo explicar perfectamente de qué estamos hablando:
- Una wiki, un entorno de edición colaborativa, llamado mediawiki. Es nuestra herramienta primaria de documentación, elaboración de tutoriales, manuales, ayudas y toda clase de elementos que requieran de edición y compartición. Es accesible por todos los miembros del proyecto, permite edición concurrente y revisión de versiones y es bastante flexible.
- Un paquete de herramientas de trabajo en grupo llamado eGroupWare. Dispone de cantidad de servicios indispensables para la coordinación de un grupo elevado de personas: agenda, calendario, lista de tareas pendientes, avisos automáticos, notas, hojas de presencia...
- Un servidor de correo POP e IMAP, cuyo motor desconozco, con la popular interfaz web squirrelmail. Todos disponemos de una dirección de correo @xatcobeo.com, accesible por los protocolos antes mencionados y por dicha interfaz web, y es la dirección a la que se mandan los avisos automáticos, de revisión de documentación o todo lo relacionado, en genreal, con nuestro trabajo en XaTcobeo.
- Un servicio de multiconferencia, es decir, salas de videoconferencia de hasta 16 participantes simultáneos, moderados, con una pizarra y compartición y visualización conjunta de documentos o del escritorio. Se llama openmeetings y parece que funciona bastante bien, y puede resultar muy útil. Basta tener un micrófono y una webcam y puedes reunirte virtualmente con los compañeros, trabajar conjuntamente, discutir...
- Un servicio de mensajería basado en XMPP/Jabber, es decir, un "messenger libre" con salas de chat privadas, por grupos de trabajo, globales, etc... Para estar en contacto. Accesible vía web o vía cliente que soporte XMPP.
- Y por último, pero no por ello menos importante, un sistema de gestión de documentación que incluye un ciclo de revisión/verificación/aprobación y firma de documentos. Por él pasarán todos los documentos que genere el proyecto y quedarán perfectamente ordenados y accesibles en una base de datos, con posibilidad de búsqueda relacional, por metadatos, etc. Está montado sobre alfresco y realiza todas estas tareas de forma casi automática con mínima interacción humana para que dé los pasos: avisa por correo de que te tienes que descargar un documento para revisión, lo haces, lo revisas y con sólo apretar un botón lo aceptas o rechazas y pasa al siguiente punto del ciclo.
Esto me recuerda que tengo que redactar la descripción funcional y técnica de la SRAD y meterla en su sitio correspondiente, que la revisen...
miércoles, 10 de septiembre de 2008
Haciendo operativo el sistema
Una de las decisiones de diseño a las que me he tenido que enfrentar últimamente es definir, al menos en lo básico, qué sistema software hará funcionar la SRAD.
El "cerebro" de la SRAD es un soft processor del tipo MicroBlaze, es decir, un microprocesador que, en vez de ser un ente hardware estático, es un ente hardware programado en la FPGA, configurable, variable, de propósito específico en cada proyecto. Y como todo microprocesador, su función es ejecutar un software. ¿Qué software?
Prácticamente cada sistema basado en microprocesador que conocemos lleva un sistema operativo. Un sistema operativo es un conjunto de instrucciones software que cumplen unas tareas muy específicas: control de recursos, interfaz de las aplicaciones con el hardware, control de la multitarea... El sentido popular que se le da a "Sistema Operativo" es de un amplio conjunto de programas y aplicaciones de usuario que vienen con el ordenador, pero, como he dicho, es una acepción popular técnicamente incorrecta. Podríamos decir que popularmente me expresaría mejor diciendo software de sistema, pero lo que quiero decir es sistema operativo.
El hardware SRAD, incluyendo el MicroBlaze, es (será) un sistema altamente específico con funcionalidades ad-hoc perfectamente definidas. Las interfaces de comunicación entre los módulos del sistema y entre el sistema y el exterior están perfectamente definidas. De este modo en principio no sería difícil programar directamente un software que accediera a dichas interfaces y, en un puñado de funciones, realizara las tareas necesarias. ¿Por qué, entonces, complicarnos la vida con un sistema operativo? Recordemos que, en todo caso, la SRAD es un sistema minúsculo, escaso de recursos, que se debe mantener tan simple como sea posible. Pues bien, un sistema operativo básico nos ofrece:
- Gestión de las funciones de acceso a los periféricos (comúnmente conocidas como controladores) organizadas en forma de primitivas.
- Control de interrupciones de usuario (tareas que pueden pedir paso de mayor preferencia al sistema).
- Planificador (muy útil): poder ejecutar varias funciones pseudo-simultáneamente.
¿Qué queda por decidir, entonces? Pues obviamente, qué sistema operativo utilizar: Windo... No, qué va, es broma...
- Un sistema extremadamente básico programado por mí mismo.
- Un Xilkernel, de Xilinx, sistema POSIX básico.
- Un núcleo Linux adaptado, como BlueCat.
Un sistema básico que yo me atrevería a hacer en los apretados plazos de los que disponemos sería un conjuntillo de funciones de cambio de contexto basadas en una interrupción por temporizador periódico (con esto obtenemos multitarea). Habría que programar bien los drivers de nuestros periféricos ad-hoc, controlar a mano la memoria y la entrada/salida de datos y tener mucho cuidado con las interrupciones de usuario. Pero eso sí, sería simple y completamente personalizado.
El Xilkernel ha sido un descubrimiento que he hecho recientemente. Me he leído la API completa, me he leído todo el manual y todos los documentos relacionados que he encontrado. Realmente me gusta. Es un sistema que implementa las funciones que he definido hace dos párrafos de forma simple y eficiente, robusta según ellos, y siguiendo el estándar POSIX, al cual estoy habituado, pues Linux es en gran parte POSIX. Realmente parece una buena opción.
BlueCat Linux me ofrece un sistema Linux integrado completo para mi MicroBlaze. Esto implica que programar software para la SRAD será como programar un dispositivo mips integrado de toda la vida con los que llevo años trabajando. Sería realmente sencillo. Pero es un sistema muchísimo más complejo de lo que nos hace falta. Más costoso en recursos hardware, y más difícil de adaptar.
Como habréis adivinado me he decantado por Xilkernel. Estoy aún en fase de adaptación, hay que conocer los entresijos del enjendro antes de hacerle cosquillas, pero creo que nos llevaremos bien. Es suficientemente flexible, muy simple y pequeño y ofrece incluso dos planificadores diferentes, interrupciones de usuario y todo eso de lo que os hablaba.
Dentro de un par de semanas espero tener una sencilla aplicación funcionando sobre un Xilkernel que a su vez funcione sobre un MicroBlaze con algún periférico que mi equipo haga a mano con propósito de prueba. Sobre una base funcional podremos construir un buen sistema simple y robusto de funciones de control que se encarguen de todas esas cosas que dije hace un par de entradas que debía hacer la SRAD.
Aún hay tiempo, hasta el 30 de octubre, para tener a punto la descripción técnica detallada del sistema completo. Poco a poco se van atando cabos. Cada vez me parece más bonito...
El "cerebro" de la SRAD es un soft processor del tipo MicroBlaze, es decir, un microprocesador que, en vez de ser un ente hardware estático, es un ente hardware programado en la FPGA, configurable, variable, de propósito específico en cada proyecto. Y como todo microprocesador, su función es ejecutar un software. ¿Qué software?
Prácticamente cada sistema basado en microprocesador que conocemos lleva un sistema operativo. Un sistema operativo es un conjunto de instrucciones software que cumplen unas tareas muy específicas: control de recursos, interfaz de las aplicaciones con el hardware, control de la multitarea... El sentido popular que se le da a "Sistema Operativo" es de un amplio conjunto de programas y aplicaciones de usuario que vienen con el ordenador, pero, como he dicho, es una acepción popular técnicamente incorrecta. Podríamos decir que popularmente me expresaría mejor diciendo software de sistema, pero lo que quiero decir es sistema operativo.
El hardware SRAD, incluyendo el MicroBlaze, es (será) un sistema altamente específico con funcionalidades ad-hoc perfectamente definidas. Las interfaces de comunicación entre los módulos del sistema y entre el sistema y el exterior están perfectamente definidas. De este modo en principio no sería difícil programar directamente un software que accediera a dichas interfaces y, en un puñado de funciones, realizara las tareas necesarias. ¿Por qué, entonces, complicarnos la vida con un sistema operativo? Recordemos que, en todo caso, la SRAD es un sistema minúsculo, escaso de recursos, que se debe mantener tan simple como sea posible. Pues bien, un sistema operativo básico nos ofrece:
- Gestión de las funciones de acceso a los periféricos (comúnmente conocidas como controladores) organizadas en forma de primitivas.
- Control de interrupciones de usuario (tareas que pueden pedir paso de mayor preferencia al sistema).
- Planificador (muy útil): poder ejecutar varias funciones pseudo-simultáneamente.
¿Qué queda por decidir, entonces? Pues obviamente, qué sistema operativo utilizar: Windo... No, qué va, es broma...
- Un sistema extremadamente básico programado por mí mismo.
- Un Xilkernel, de Xilinx, sistema POSIX básico.
- Un núcleo Linux adaptado, como BlueCat.
Un sistema básico que yo me atrevería a hacer en los apretados plazos de los que disponemos sería un conjuntillo de funciones de cambio de contexto basadas en una interrupción por temporizador periódico (con esto obtenemos multitarea). Habría que programar bien los drivers de nuestros periféricos ad-hoc, controlar a mano la memoria y la entrada/salida de datos y tener mucho cuidado con las interrupciones de usuario. Pero eso sí, sería simple y completamente personalizado.
El Xilkernel ha sido un descubrimiento que he hecho recientemente. Me he leído la API completa, me he leído todo el manual y todos los documentos relacionados que he encontrado. Realmente me gusta. Es un sistema que implementa las funciones que he definido hace dos párrafos de forma simple y eficiente, robusta según ellos, y siguiendo el estándar POSIX, al cual estoy habituado, pues Linux es en gran parte POSIX. Realmente parece una buena opción.
BlueCat Linux me ofrece un sistema Linux integrado completo para mi MicroBlaze. Esto implica que programar software para la SRAD será como programar un dispositivo mips integrado de toda la vida con los que llevo años trabajando. Sería realmente sencillo. Pero es un sistema muchísimo más complejo de lo que nos hace falta. Más costoso en recursos hardware, y más difícil de adaptar.
Como habréis adivinado me he decantado por Xilkernel. Estoy aún en fase de adaptación, hay que conocer los entresijos del enjendro antes de hacerle cosquillas, pero creo que nos llevaremos bien. Es suficientemente flexible, muy simple y pequeño y ofrece incluso dos planificadores diferentes, interrupciones de usuario y todo eso de lo que os hablaba.
Dentro de un par de semanas espero tener una sencilla aplicación funcionando sobre un Xilkernel que a su vez funcione sobre un MicroBlaze con algún periférico que mi equipo haga a mano con propósito de prueba. Sobre una base funcional podremos construir un buen sistema simple y robusto de funciones de control que se encarguen de todas esas cosas que dije hace un par de entradas que debía hacer la SRAD.
Aún hay tiempo, hasta el 30 de octubre, para tener a punto la descripción técnica detallada del sistema completo. Poco a poco se van atando cabos. Cada vez me parece más bonito...
jueves, 4 de septiembre de 2008
Difícil septiembre
Un ligero inconveniente de un proyecto de gran magnitud llevado por estudiantes es que, precisamente, en algunas épocas les toca estudiar. Estamos en septiembre, y es un mes difícil para la mayoría de los estudiantes. En la Universidad de Vigo los exámenes son del 1 al 15 de septiembre. En los laboratorios de XaTcobeo estamos bajo mínimos. La primera consecuencia es que los que quedamos tenemos que diversificarnos por un par de semanas.
Esta semana le he hecho poco caso a la SRAD. He tenido que poner a punto la que será la página web del proyecto (no os la puedo enseñar de momento), así como la wiki interna para desarrolladores (que no os podré enseñar nunca) y hacer pruebas de usabilidad y estabilidad sobre las herramientas de trabajo en grupo (más de lo mismo).
Pero claro, no se puede perder la perspectiva. El día 30 de este mes debo tener lista la descripción funcional de la SRAD. ¿Y esto qué es? Pues un documento en correcto inglés con poca letra y muchos diagramas que expliquen en tres niveles de abstraccióń cómo funciona la SRAD. Es algo como lo que cuento aquí pero en formal y en inglés, y que luego habrá que publicar. A saber:
- Descripción de las funciones a nivel global: transmisión de datos entre el satélite y la estación terrena.
- Descripción de las funciones de la SRAD como componente del satélite: comunicación con el ordenador de a bordo, con la interfaz de radio...
- Descripción de los módulos funcionales internos a la SRAD: módulos de control, de codificación, interfaces...
El día 22 doy una conferencia en Münster, Alemania, precisamente sobre la SRAD. Aprovecharé los bonitos (espero) diagramas que haré para la descripción funcional para tener algo decente que mostrar allá, porque si no les tendré que volver a soltar más o menos lo mismo que dije en Utah, aunque un poco más detallado.
En otro orden de cosas... Parece que este blog ha gustado en ciertos círculos, si no me han mentido. Y digo yo, ¿por qué nadie comenta nada? ¿Miedo a que parezca que me lee alguien? Si es que...
Jajaja, mañana más.
Esta semana le he hecho poco caso a la SRAD. He tenido que poner a punto la que será la página web del proyecto (no os la puedo enseñar de momento), así como la wiki interna para desarrolladores (que no os podré enseñar nunca) y hacer pruebas de usabilidad y estabilidad sobre las herramientas de trabajo en grupo (más de lo mismo).
Pero claro, no se puede perder la perspectiva. El día 30 de este mes debo tener lista la descripción funcional de la SRAD. ¿Y esto qué es? Pues un documento en correcto inglés con poca letra y muchos diagramas que expliquen en tres niveles de abstraccióń cómo funciona la SRAD. Es algo como lo que cuento aquí pero en formal y en inglés, y que luego habrá que publicar. A saber:
- Descripción de las funciones a nivel global: transmisión de datos entre el satélite y la estación terrena.
- Descripción de las funciones de la SRAD como componente del satélite: comunicación con el ordenador de a bordo, con la interfaz de radio...
- Descripción de los módulos funcionales internos a la SRAD: módulos de control, de codificación, interfaces...
El día 22 doy una conferencia en Münster, Alemania, precisamente sobre la SRAD. Aprovecharé los bonitos (espero) diagramas que haré para la descripción funcional para tener algo decente que mostrar allá, porque si no les tendré que volver a soltar más o menos lo mismo que dije en Utah, aunque un poco más detallado.
En otro orden de cosas... Parece que este blog ha gustado en ciertos círculos, si no me han mentido. Y digo yo, ¿por qué nadie comenta nada? ¿Miedo a que parezca que me lee alguien? Si es que...
Jajaja, mañana más.
martes, 2 de septiembre de 2008
Una imagen vale más que mil palabras
Si una imagen vale más que mil palabras espero que una animación, por cutre que sea, valga más que toda la parrafada de ayer. Preparé esta pequeña y curiosa animación para la presentación del proyecto a la prensa, allá por junio. Esta es la versión recortada, había preparado una con tres órbitas, pero resultaba muy larga para ellos.
lunes, 1 de septiembre de 2008
Utah 2008 (II)
Siempre haciendo hincapié en la importancia en sí del proyecto XaTcobeo como sistema de formación, vamos a hablar hoy de qué vamos a llevar dentro del satélite. A parte de los sistemas propios de alimentación y control (de los que hablaremos en sesiones posteriores) el satélite llevará tres experimentos o cargas útiles: un sistema de despliegue de paneles solares, un medidor de dosis de radiación ionizante y, como experimento principal, una SDR (Software Defined Radio, radio definida por software) a la que llamamos SRAD. Y dicho SRAD, sistema del que yo soy responsable, fue el tema que expuse en el congreso de Utah y del que hablaré en septiembre en otro congreso en Alemania. ¿Qué es, entonces, la SRAD? Recordemos que hablamos de un satélite de 10x10x10 centímetros y menos de 1kg de peso, ¿eh?
Como su propio nombre indica, es un sistema de transmisión y recepción de señales de radio definido mediante software. Al contrario que una emisora de radio convencional, una SDR puede "destruirse" y ser sustituida por una nueva con otras funcionalidades y características mediante comandos software. Se puede intuir que esto tendrá gran cantidad de ventajas cuando hablamos de un pequeño artefacto volando a 400 kilómetros de La Tierra. Y, ¿cómo se puede definir un sistema radio por software? Todo el que no sepa lo que es una FPGA, que siga el enlace y lea el artículo. ¿A que ahora ya se empieza a ver la luz? Pues una FPGA es un dispositivo cuya funcionalidad se puede reprogramar, creando de esta forma un circuito diferente en el mismo dispositivo electrónico.
Una vez presentado y disponible el sustrato sobre el que construir nuestro diseño pensaremos... ¿Tiene esto algo de nuevo? ¿Tanto revuelo por un dispositivo reprogramable? Pues la cuestión es que no hay a penas precedentes de FPGAs volando en satélites, en duras condiciones de radiación. Por otro lado un satélite tan pequeño no tiene a penas potencia disponible para hacer muchos juegos, y la optimización es muy complicada. En tercer lugar, hacen falta ideas y un gran proceso de ingeniería para diseñar un sistema que sea robusto y versátil, suficientemente simple como para estar seguros de que va a funcionar y suficientemente sofisticado como para poder experimentar con él. No es, en ningún caso, tarea simple. Pero démosle una vuelta de tuerca más. En una FPGA cuanto más complejo es el sistema programado mayor es el consumo. Y en nuestro cacharrito no tenemos casi potencia disponible. ¿Qué tal si nos curramos un sistema que reprograme y autorregule la complejidad del sistema en función de las características del medio? Pues así como se me ocurrió salió el diseño de la siguiente imagen.
Nuestro sistema incluirá una parte software que se ejecutará en un procesador a su vez definido por software en la FPGA que implementará una serie de rutinas de control y una serie de módulos de procesado de radio. Por otro lado tendremos un diseño de hardware de codificadores de radio directamente en la FPGA. Este último caso es más rápido, pero mucho más ávido de potencia eléctrica, mientras que el procesado software es lento pero liviano. Un protocolo de bus de sistema conectará nuestra radio con el ordenador de a bordo, de donde recibirá instrucciones y un conjunto de rutinas especiales controlaran todas las definiciones software que incorporará la SRAD y las cargará según sea necesario. Además tendremos espacio libre, puesto que si la SRAD es un éxito podremos enviar desde nuestra estación en tierra nuevos datos de configuración. Este complejo sistema no pasó desapercibido entre nuestros colegas ingenieros en Utah, y allí recopilé datos y opiniones de gente de todo el mundo. Escepticismo en general para un proyecto tan innovador, pero ánimos y buenas palabras para intentarlo.
El diseño ya lo tengo sobre la mesa. Tengo un equipo de ingeniería que es capaz de esto y de mucho más. Tenemos alrededor de 12 meses de plazo. Llevamos consumido uno.
Vega, allá vamos.
Como su propio nombre indica, es un sistema de transmisión y recepción de señales de radio definido mediante software. Al contrario que una emisora de radio convencional, una SDR puede "destruirse" y ser sustituida por una nueva con otras funcionalidades y características mediante comandos software. Se puede intuir que esto tendrá gran cantidad de ventajas cuando hablamos de un pequeño artefacto volando a 400 kilómetros de La Tierra. Y, ¿cómo se puede definir un sistema radio por software? Todo el que no sepa lo que es una FPGA, que siga el enlace y lea el artículo. ¿A que ahora ya se empieza a ver la luz? Pues una FPGA es un dispositivo cuya funcionalidad se puede reprogramar, creando de esta forma un circuito diferente en el mismo dispositivo electrónico.
Una vez presentado y disponible el sustrato sobre el que construir nuestro diseño pensaremos... ¿Tiene esto algo de nuevo? ¿Tanto revuelo por un dispositivo reprogramable? Pues la cuestión es que no hay a penas precedentes de FPGAs volando en satélites, en duras condiciones de radiación. Por otro lado un satélite tan pequeño no tiene a penas potencia disponible para hacer muchos juegos, y la optimización es muy complicada. En tercer lugar, hacen falta ideas y un gran proceso de ingeniería para diseñar un sistema que sea robusto y versátil, suficientemente simple como para estar seguros de que va a funcionar y suficientemente sofisticado como para poder experimentar con él. No es, en ningún caso, tarea simple. Pero démosle una vuelta de tuerca más. En una FPGA cuanto más complejo es el sistema programado mayor es el consumo. Y en nuestro cacharrito no tenemos casi potencia disponible. ¿Qué tal si nos curramos un sistema que reprograme y autorregule la complejidad del sistema en función de las características del medio? Pues así como se me ocurrió salió el diseño de la siguiente imagen.
Nuestro sistema incluirá una parte software que se ejecutará en un procesador a su vez definido por software en la FPGA que implementará una serie de rutinas de control y una serie de módulos de procesado de radio. Por otro lado tendremos un diseño de hardware de codificadores de radio directamente en la FPGA. Este último caso es más rápido, pero mucho más ávido de potencia eléctrica, mientras que el procesado software es lento pero liviano. Un protocolo de bus de sistema conectará nuestra radio con el ordenador de a bordo, de donde recibirá instrucciones y un conjunto de rutinas especiales controlaran todas las definiciones software que incorporará la SRAD y las cargará según sea necesario. Además tendremos espacio libre, puesto que si la SRAD es un éxito podremos enviar desde nuestra estación en tierra nuevos datos de configuración. Este complejo sistema no pasó desapercibido entre nuestros colegas ingenieros en Utah, y allí recopilé datos y opiniones de gente de todo el mundo. Escepticismo en general para un proyecto tan innovador, pero ánimos y buenas palabras para intentarlo.El diseño ya lo tengo sobre la mesa. Tengo un equipo de ingeniería que es capaz de esto y de mucho más. Tenemos alrededor de 12 meses de plazo. Llevamos consumido uno.
Vega, allá vamos.
Suscribirse a:
Entradas (Atom)
Entradas
