Lista de funcionalidades a realizar - plaa/Modular GitHub Wiki

Esta lista está destinada principalmente a los desarrolladores de aplicaciones en entorno Java. Aquí se detallan algunas de las características que se desean implementar en un futuro para OpenRocket, y otras que también se pueden llevar a cabo razonablemente, sin tener un conocimiento profundo del funcionamiento interno de OpenRocket. Si tiene algo con lo que que te gustaría contribuir (o hacerlo Vd. mismo), por favor infórmenos al respecto en la Lista de correo para el desarrollo-OpenRocket y tal vez podamos ayudarle a empezar.

Esta página complementa a la distribuición del archivo TODO que contiene más ideas, pero en una forma más corta. Por favor, haga todos los comentarios que desee sobre los temas.

Table of Contents

Mejoras de la interfaz del usuario

Hay varios aspectos que necesitan atención en la interfaz del usuario. El código de la interfaz del usuario también se encuentra un poco desordenado en algunos lugares, y debe ponerse en orden.

  • Zoom intuitivo de las gráficas
    • Incluir botones de lupa para hacer zoom in / out
    • Actualmente si se hace clic sobre el gráfico y se arrastra hacia la parte inferior derecha, la gráfica aumenta, y si se hace hacia la parte superior izquierda se reinicia el zoom al original - muy poco intuitivo (por defecto JFreeChar)
    • Debe implementarse como un componente genérico que pudiera utilizarse en diferentes lugares
  • Ctrl + rueda de desplazamiento debe acercar / alejar el diseño del cohete (y quizás también las gráficas)
  • Component databases

Vista en 3D del cohete

Una vista 3D del cohete es muy deseable, pero no tengo ninguna experiencia en programación en 3D. A continuación se presentan algunas ideas o "lista de deseos" (¡no todas necesitan implementarse!)

  • Probablemente tendrá que usar Java 3D (parece ser el estándar de facto)
  • La vista en 3D como alternativa a la vista lateral y posterior del cohete
    • Rotación con el ratón arrastrar y soltar
    • Posibilidad de que los componentes exteriores sea translúcida
  • Una animación del vuelo simulado
    • Descripción general del vuelo (con posibilidad de ampliar el cohete)
    • Una vista cercana del cohete durante el vuelo, con los ejes x, y, z visibles
      • Proporcionar una visualización de lo que está haciendo el cohete durante el vuelo
      • El movimiento del cohete, a menudo muy difícil de visualizar mirando sólo los gráficos
      • Pueden necesitarse otros parámetros del vuelo que se almacenan durante la simulación

Soporte para la impresión

La impresión es una de las características más solicitadas para OpenRocket. Al mismo tiempo, sería natural permitir la exportación de los mismos en formato PNG, SVG o PDF.

El soporte puede implementarse en distintos niveles. Al menos los siguientes aspectos son candidatos deseables para imprimir/exportar:

  • Las plantillas de las aletas y las transiciones, y los perfiles de la ojiva
  • La vista del diseño del cohete
  • Las gráficas de la simulación (JFreeChart tiene soporte incorporado)
  • Impresión de un informe del diseño (ver más abajo)

Crear/imprimir un informe del diseño del cohete

Capacidad de crear un informe que contenga la información más importante del diseño, para presentársela al RSO durante un evento de lanzamientos. La estructura del informe podría ser algo parecido a:

  • Título
  • Sección donde se describe el cohete en general, sin el motor
    • Nombre del diseño
    • Masa y CG en vacío
    • Posición del CP
    • Posición del CP a 5º de AOA (o similar)
    • El número de etapas
    • Tamaños de Paracaídas/Banderola
    • Diámetro máximo (calibre)
  • Sección para cada configuración de motor
    • Un resumen de los motores instalados, por ejemplo, 3xC6-0, B4-6
    • Una lista de los motores instalados, el fabricante, la designación (quizás también información sobre la duración de la combustión, los gramos de propulsor, el impulso total)
    • Masa total del propelente en gramos
    • Impulso total
    • Peso de despegue
    • La posición del CG y del CP, el margen de estabilidad
    • Predicción de la altitud máxima de vuelo, la velocidad máxima, y la aceleración máxima
    • La velocidad predicha en el instante del despliegue del paracaídas/banderola
    • La velocidad predicha de descenso
  • Diagrama del cohete (en posición vertical en el lado derecho de la primera página)
    • Posición del CP
    • Posición del CG, sin el motor y en cada configuración (las etiquetas deben alternarse en los lados derecho e izquierdo para evitar que queden encima de las otras)
El procedimiento para los usuarios podría ser algo como:
  • Seleccione el menú Cohete -> Diseño del informe
  • Se abre un diálogo para pedir que las configuraciones de motor se incluyan en el informe
    • Quizá incluso pedir el tamaño del papel, o semejante
  • Se ejecutan todas las simulaciones con el objeto de conseguir una información más actualizada
  • El informe se muestra al usuario, lo que les permite guardar o imprimir
Consideraciones técnicas:
  • Fácil acceso a los datos predichos de desde OR (consultar)
  • La trama de cohetes puede y debe utilizar la misma representación que en la ventana del diseño
  • ¿Cómo definir las condiciones del lanzamiento?. Debería el usuario seleccionar "simulaciones" para incluir en el informe, en lugar de "configuraciones de motor"?
Otro asunto es en qué formato y de qué forma crear el informe. A continuación mostramos algunas alternativas que se han considerado, las demás también son posibles.
  • Generar el informe en HTML
    • Pros:
      • Fácil de generar
      • Se puede mostrar mediante un JTextPane
      • Permite guardar como HTML
      • Fácil de imprimir desde Java con JTextComponent.print()
    • Contras:
      • Si se incluye el gráfico, podría ser problemático, y requeriría un archivo independiente al guardar el diseño
      • El diagrama del cohete tiene que ser en formato raster
      • No hay soporte para la paginación inteligente
  • Utilizar iText o algún otro generador de PDF
    • Pros:
      • Exportar directamente como PDF, sólo un archivo de salida
      • Mayor control, puede producir una salida de aspecto más profesional
      • El diagrama del cohete puede ser en formato vectorial
      • Puede paginarse mejor
    • Contras:
      • Puede ser más difícil de generar (?)
      • La paginación inteligente puede ser un desafío al requerir un trabajo adicional
      • La visualización e impresión del informe pueden necesitar apoyo por separado (tal vez usando PDFBox?)




Perfiles de memoria

OpenRocket parece que consume bastante memoria, y es probable que haya numerosas fugas de memoria. (Durante el desarrollo inicial se hacía esfuerzo en conseguir que funcionara, no se hacía una gestión de la memoria.) A continuación se presentan algunas sugerencias que podrían hacerse para mejorar la gestión de la memoria.

  • Perfil de uso de la memoria en OpenRocket, para encontrar posibles fugas
  • Poner en práctica una tarea programada que comprueba el uso de la memoria cada diez segundos más o menos
    • Advertir al usuario cuando se esté utilizando el 90% de la memoria disponible
    • Posibilidad de enviar de forma automática los perfiles de los datos de la memoria a los desarrolladores (?)

Mejoras del cálculo aerodinámico

Mientras OpenRocket produce resultados razonablemente precisos para modelos de cohete típicos, hay muchos casos que necesitan de una atención especializada.

En la mayoría de los casos, la implementación la pueden hacer los desarrolladores del núcleo, ¡si se dispone sólo de métodos claros!

  • Las estimaciones del arrastre y del CG a altas velocidades supersónicas (> 1,5 M) son pobres
  • Soporte para componentes adicionales, tales como aceleradores externos ("pods") y las aletas tubulares
    • Es necesaria la estimación del CG, el CNa y el coeficiente de arrastre
  • Estimación de la tasa de rotación alrededor de un factor de dos, por razones desconocidas (ver secciones 3.3 y 6.3 de la [documentación])
  • Cálculo de la fuerza aerodinámica usando CFD (Dinámica de fluidos computacional)
    • Preferentemente de un paquete estándar como Elmer o [OpenFOAM]
    • Comunicación, ya sea usando JNI o ​​stdin/stdout a un archivo ejecutable independiente
    • La implementación requiere al menos:
      • Creación de la malla de simulación
      • Llamar al método de cálculo
      • Deducir las fuerzas y momentos (preferiblemente que sea capaz de discriminar la contribución de los diferentes componentes)
      • Cache y la interpolación de datos para la simulación eficiente
    • ¡Una visualización sería una gran ventaja!
⚠️ **GitHub.com Fallback** ⚠️