![]() |
|
|
|
| VHF: Canal 77 |    | ![]() |
![]() |
![]() |
![]() |
![]() |
|
|
|
#1
|
||||
|
||||
|
Si, puedo crear STL sin problema.
El dock para el movil puedo diseñarlo, el problema es la diversidad de tamaños, donde colocar el conector... quiero decir que habría que rediseñar para cada modelo de movil.
__________________
<')(((>< <')(((>< <')(((>< Que es mi barco mi tesoro, que es mi dios la libertad, mi ley, la fuerza y el viento, mi única patria, la mar. https://www.facebook.com/pages/Juriola/214037382001173 Documentación y fotos de la construcción: https://www.dropbox.com/sh/u7ktl11am...uOakJ4Y3a?dl=0 |
|
#2
|
||||
|
||||
|
Buenas taberneros developpers,
quisiera saber porqué habéis renunciado a la opción de conexión por Bluetooth. A mi no me iba ni tan mal. Como no sé de desarrollar para Android y tampoco quería sumergirme demasiado en el desarrollo para esta plataforma usé el MIT App Inventor. Usaba el envío de caracteres o números enteros desde la App al hacer click sobre alguno de los botones de la interface: -1 grado, +1 grado, -10, +10, centrar, etc... que el loop de lectura de la entrada de datos por Bluetooth leía y modificaba los datos almacenados en memoria temporal en consecuencia. Desde luego nunca traté de usar una solución de checksum para validar que los datos TX/RX no se recibieran corruptos debido a alguna interferencia u otro error. Pero el código sólo aceptaba la entrada de datos si se correspondía con el carácter o entero enviado, de lo contrario quedaba descartado. El retorno del Arduino hacia el móvil me enviaba en una sola sentencia varios datos como el Rumbo deseado versus el Rumbo real, posición del zafrán, velocidad y algunos datos de debugging para pruebas. Aunque para los tests solía conectar directamente el portátil al arduino y recogía toda la información para poder ir ajustando el algoritmo PID. En definitiva, el Bluetooth no me iba tan mal y creo que facilitaría el problema de tipo de interface de conexión entre móvil y piloto automático. El MIT App Inventor me permitió hacer una interface bastante sencilla, con un buen contraste para ver bien a pleno sol. El ratio de envío y recepción de datos sí que me solía dar algún quebradero de cabeza. A una velocidad de 1 mensaje por segundo todo iba bien, si bajaba mucho se perdían bastantes datos y el refresco no era el esperado. Una pena porque la brújula de la interface quedaba más chula si el refresco era rápido. Este es el aspecto de la interface: Bueno, perdón por el tostón sólo para que persistáis con Bluetooth que creo que daría más versatilidad al Fenix. Un saludo cordial ![]() Txalamar. |
|
#3
|
||||
|
||||
|
Cita:
Actualmente la comunicación entre Virtuino (App de móvil) y Fenix (Arduino) se realiza de tal modo que cada 1 seg, se vuelcan todos los datos desde un dispositivo al otro y viceversa. Este sistema no es eficiente porque evidentemente la mayor parte de los datos no cambian de un segundo a otro. Hay una nueva versión de Virtuino que implementa un nuevo protocolo de comunicación que sólo envía los datos que cambian, lo cual es un avance significativo. Para evolucionar a la nueva versión tengo que hacer cambios en el código Arduino, y espero con ello mejorar la calidad de la comunicación. Por cierto, buena referencia el MIT App Inventor. Parece que da más posibilidades de programación que Virtuino. Saludos, Sergio |
| Los siguientes cofrades agradecieron este mensaje a spascual90 | ||
Loquillo (15-12-2020) | ||
![]() |
Ver todos los foros en uno |
| Etiquetas |
| arduino, bricobarco, piloto automático caña |
| Herramientas | |
| Estilo | |
|
|