Tutorial de comando y control
Introducción
Command and Control es una nueva plantilla de LabVIEW agregada para la temporada 2016 que organiza el código del robot en comandos y controladores para una colección de subsistemas específicos del robot. Cada subsistema tiene un bucle de control independiente o una máquina de estado que se ejecuta a la velocidad adecuada para el mecanismo y los comandos de alto nivel que actualizan las operaciones y los puntos de ajuste deseados. Esto hace que sea muy fácil para el código autónomo construir secuencias síncronas de comandos. Mientras tanto, TeleOp se beneficia porque puede usar los mismos comandos sin necesidad de esperar a que se completen, lo que permite una fácil cancelación e inicio de nuevos comandos de acuerdo con la entrada del equipo de manejo. Cada subsistema tiene un panel que muestra sus valores de sensor y control a lo largo del tiempo, y seguimiento de comandos para ayudar en la depuración.
¿Qué es Command and Control?
Command and Control reconoce que los robots FRC® tienden a estar formados por mecanismos relativamente independientes como Drive, Shooter, Arm, etc. Cada uno de estos se conoce como un subsistema y necesita un código que coordine los diversos sensores y actuadores del subsistema para completar los comandos solicitados. o acciones, como «Cerrar pinza» o «Brazo inferior». Uno de los principios clave de este marco es que los subsistemas tendrán cada uno un circuito de controlador independiente que es el único responsable de actualizar los motores y otros actuadores. El código fuera del controlador del subsistema puede emitir comandos que pueden cambiar la salida del robot, pero no deben cambiar directamente ninguna salida. La diferencia es muy sutil, pero esto significa que los resultados solo pueden actualizarse desde una ubicación en el proyecto. Esto acelera la depuración de un robot que se comporta de manera inesperada al brindarle la capacidad de revisar una lista de comandos enviados al subsistema en lugar de buscar en su proyecto donde se haya modificado una salida. También se vuelve más fácil agregar un sensor adicional, cambiar de marcha o deshabilitar un mecanismo sin necesidad de modificar el código fuera del controlador.
El código del juego, principalmente consiste en el Autónomo y Teleoperado, va a necesitar actualizar los puntos de ajuste y reaccionar al estado de ciertos mecanismos. Para el Autónomo, es muy común definir la operación del robot como una secuencia de operaciones – maneja aquí, recoge eso, llévalo allá, dispara, etc. Los comandos se pueden conectar secuencialmente con lógica adicional para construir rápido rutinas complejas. Para Teleoperado, los mismos comandos pueden operar de manera síncrona, dejando que el robot siempre procese las últimas entradas del driver, y si lo implementa apropiadamente, nuevos comandos van a interrumpir, dejando que el drive team responda rápido en las condiciones de la cancha mientras también toma ventaja de comandos automatizados y secuencias de comandos.
¿Por qué debemos usar Command and Control?
Command and Control añade funcionalidad a las plantillas de proyecto existentes en LabVIEW, permitiendo que el código se escale mejor con robots y códigos de robot mas sofisticados. Se usan subsistemas para abstraer los detalles de la implementación, y el código de juego es creado a partir de secuencias de VIs de comando de alto nivel. Los comandos por si mismos son VIS que pueden actualizar puntos fijos, realizar mapeo/escalado numérico entre unidades de ingeniería y unidades del mecanismo y pueden ofrecer opciones de sincronización. Si se realizan cambios físicos al robot, como modificar un a relaciona de engranes, se pueden realizar los cambios a solo un poco de VIs de comando para reflejar este cambio a través de todo el código fuente.
La encapsulación I/O ayuda a tener una operación mas predecible y una depuración mas rápida en caso de que ocurran conflictos entre los recursos. Debido a que cada comando es un VI, puede realizar un solo paso a través de los comandos o utilizar la funcionalidad Trace incorporada para ver una lista de todos los comandos enviados a cada subsistema. de comandos o agregue una lógica simple para determinar el comando correcto para ejecutar.
Parte 1: Explorador de proyectos
El Explorador de proyectos proporciona organización para todos los Vis y archivos que usted usará para su sistema de robot. A continuación se muestra una descripción de los componentes principales del Explorador de proyectos para ayudar con la expansión de nuestro sistema. Los elementos utilizados con más frecuencia se han marcado en negrita.
- Mi computadora
Los elementos que definen la operación en la computadora en la que se cargó el proyecto. Para un proyecto de robot, esto se utiliza como un objetivo de simulación y se completa con archivos de simulación.
- Archivos de soporte de Sim
The folder containing 3D CAD models and description files for the simulated robot.
- Simulación del robot Readme.html
Documents the PWM channels and robot info you will need in order to write robot code that matches the wiring of the simulated robot.
- Posesiones
Muestra los archivos usados en la simulación del código del robot. Esto se completará cuando designe el código para el objetivo del robot simulado.
- Especificaciones de construcción
Esto contendrá los archivos que definen cómo construir y desplegar el código para el objetivo de robot simulado.
- Objetivo (roboRIO-TEAM-FRC.local)
Los elementos que definen la operación en el roboRIO ubicado en (dirección).
- Unidad
La implementación del subsistema y los comandos para la base de accionamiento del robot. Esto sirve como un reemplazo personalizado para los VIs de WPILib RobotDrive.
- Marco de trabajo
VI utilizados para código de robot que no forma parte de un subsistema que no se utilizan con mucha frecuencia.
- Comienzo
Se manda a llamar una vez cuando el código del robot comienza. Esto es útil para códigos de iniciación que no pertenecen a un subsistema en particular.
- Deshabilitado
Se llama una vez por cada paquete deshabilitado y se puede usar para depurar sensores cuando no desea que el robot se mueva.
- Terminar
Durante el desarrollo, esto puede ser llamado cuando el código del robot termine. No se llama «abortar» o cuando se apaga la energía.
- Tareas periódicas
Un buen lugar para los bucles periódicos ad hoc para la depuración o la vigilancia
- Datos globales del robot
Útil para compartir información de los robots que no pertenece a un subsistema.
- Código de apoyo
Ayudas para la depuración y el desarrollo de códigos.
- Visión
Subsistema y comandos para la cámara y el procesamiento de imágenes.
- Robot Main.vi
El máximo nivel VI que se ejecutará mientras se desarrolla el código.
- Autonomous.vi
VI que se desarrolla durante el período autónomo.
- Teleop.vi
VI que se llama para cada paquete de TeleOp.
- Test.vi
VI que se ejecuta cuando la «driver station» está en modo de prueba.
- SubSystems.vi
VI que contiene y pone en marcha todos los subsistemas.
- Posesiones
Muestra los archivos usados por el código del robot.
- Especificaciones de construcción
Se usa para construir y ejecutar el código como una aplicación de inicio una vez que el código funciona correctamente.
Explorador del proyecto del subsistema de conducción
- Comandos:
Esta carpeta contiene el comando VIs que solicita al controlador realizar una operación. Además contiene plantillas para crear comandos de unidad adicionales.
Nota
Después de crear un nuevo comando, podría necesitar editar Drive Setpoints.ctl para añadir o actualizar campos que el controlador usa para definir la nueva operación. También podría necesitar ir dentro del Drive Controller.vi y modificar la estructura del caso para añadir un caso para cada valor.
Implementación
Estos son los VIs y Controles usados para construir el subsistema.
- Infraestructura VIs
Comprobación de conducción para el Nuevo Comando: Se llama cada iteración del bucle controlador. Comprueba si hay nuevos comandos, actualiza los datos de tiempo, y al terminar notifica un comando de espera.
Conduzca el Ayudante de Comando.vi: Los comandos llaman a este VI para notificar al controlador que se ha emitido un nuevo comando.
Drive Controller Initialization.vi: Asigna el notificador y combina el tiempo, el comando predeterminado y otra información en un solo cable de datos.
Drive Controller.vi: Este VI contiene el bucle de la máquina de control/estado. El panel también puede contener pantallas útiles para la depuración.
Drive Operation.ctl: Este tipedef define los modos de funcionamiento del controlador. Muchos comandos pueden compartir una operación.
Drive Setpoint.ctl: Contiene los archivos de datos usados por todos los modos de funcionamiento del subsistema Drive.
Drive Published Globals.vi:: Un lugar útil para publicar información global sobre el subsitema drive.
Parte 2: Iniciando el subsistema de accionamiento
Hay comentarios en verde en el diagrama de bloques del controlador que señalan áreas clave que querrás saber cómo editar.
El área a la izquierda del bucle de control se ejecutará una vez cuando el subsistema se ponga en marcha. Aquí es donde normalmente se asignarán e inicializarán todos los datos de E/S y de estado. Puedes publicar los refnums de E/S, o puedes registrarlos en el modo de prueba sólo para mantenerlos privados de modo que otros códigos no puedan actualizar los motores sin usar un comando.
Nota
La inicialización de los recursos de cada subsistema en su respectivo Controller.vi en lugar de en Begin.vi mejora la encapsulación de E/S, reduciendo los posibles conflictos de recursos y simplifica la depuración.
Parte de la inicialización consiste en seleccionar la operación predeterminada y los valores de punto de ajuste cuando no se está procesando ninguna otra operación.
Dentro del bucle de control hay una declaración de caso donde las operaciones se llevan a cabo realmente. Los valores del punto de ajuste, el retardo de iteración, el recuento de iteración y los sensores pueden influir en el funcionamiento del subsistema. Esta estructura de caso tiene un valor para cada estado de operación del subsistema.
Cada iteración del bucle controlador actualizará opcionalmente el Trace VI. El marco ya incorpora el nombre del subsistema, la operación y la descripción, y puede resultar útil dar formato a valores de puntos de ajuste adicionales en la información de la traza. Abra el Trace VI y haga clic en Activar mientras el código del robot se ejecuta a los puntos de ajuste actuales y a los comandos enviados a cada subsistema.
El objetivo principal del controlador es actualizar los actuadores del subsistema. Esto puede ocurrir dentro de la estructura de la caja, pero muchas veces, es beneficioso hacerlo aguas abajo de la estructura para asegurar que los valores se actualizan siempre con el valor correcto y en una sola ubicación en el código.
Parte 3: Comandos enviados por el subsistema de conducción
Hay 3 comandos de ejemplo enviados para cada nuevo subsistema:
Conduzca por el tiempo.vi
Este VI pone los motores en marcha durante un número determinado de segundos. Opcionalmente se sincroniza con la finalización del comando.
El caso Drive for Time hará funcionar los motores en el punto de ajuste hasta que el temporizador transcurra o se emita un nuevo comando. Si los motores tienen el tiempo de seguridad habilitado, es necesario actualizar los motores al menos una vez cada 100ms. Por eso el código espera el menor de los tiempos restantes y 50ms.
Conduzca inmediatamente.vi
Consigue las velocidades izquierda y derecha deseadas para los motores y ajustará los motores inmediatamente a esos puntos de ajuste.
El caso inmediato actualiza los motores al punto de ajuste definido por el comando. El comando no se considera terminado ya que se quiere que los motores mantengan este valor hasta que llegue un nuevo comando o hasta un valor de tiempo de espera. El tiempo de espera es útil siempre que un comando incluye una banda muerta. No se solicitarán valores pequeños si son menores que la banda muerta, y resultarán en gruñidos o arrastramientos a menos que el comando se agote.
Stop Driving.vl
Detiene los motores, haciendo que el robot permanezca estacionario.
El comando de reserva apaga los motores y espera un nuevo comando. Cuando se utiliza con una secuencia de comandos con nombre, reserva identifica que el subsistema de accionamiento forma parte de una secuencia, incluso si no está moviendo el robot en ese momento. Esto ayuda a arbitrar el recurso del subsistema entre los comandos que se ejecutan simultáneamente.
Parte 4: Creando Comandos Nuevos
El comando y el Control framework permite a los usuarios crear fácilmente nuevos comandos para un subsistema. Para crear un nuevo comando abra la carpeta del subsistema/Comandos en la ventana del explorador de proyectos, seleccione una de las plantillas de VI para usar como partida inicial de su nuevo comando, clic derecho, y seleccione Nuevo Desde Plantilla.
Inmediato: Este VI notifica al subsistema sobre el nuevo punto de ajuste.
Inmediatamente con la banda muerta: Este VI compara el valor de entrada con la banda muerta y opcionalmente notifica al subsistema sobre el nuevo punto de ajuste. Esto es muy útil cuando se utilizan valores continuos de joystick.
Con la duración: Este VI notifica al subsistema para que realice este comando durante la duración dada, y luego volver al estado por defecto. La sincronización determina si este VI inicia la operación y regresa inmediatamente, o espera a que la operación se complete. La primera opción se usa comúnmente para TeleOp, y la segunda para Secuenciación Autónoma.
En este ejemplo, agregaremos el nuevo comando «Conducir por distancia».
Primero, guarde el nuevo VI con un nombre descriptivo como «Drive for Distance». A continuación, determine si el nuevo comando necesita un nuevo valor agregado en Drive Operations enum typedef. El código del proyecto inicial ya tiene un valor de enumeración de Drive for Distance, pero la siguiente imagen muestra cómo agregaría uno si fuera necesario.
Si un comando necesita información adicional para ejecutarse, añádalo al control de puntos de ajuste. Por defecto, el subsistema Drive tiene campos para el Left Setpoint, Right Setpoint y Duration junto con la operación que se va a ejecutar. El comando Drive for Distance podría reutilizar la duración como distancia, pero sigamos adelante y agreguemos un control numérico a Drive Setpoints.ctl llamdo Distance (pies).
Una vez que tenemos todos los campos necesarios para especificar nuestro comando, podemos modificar el recién creado Drive for Distance.vi. Como se muestra a continuación, seleccione Drive for Distance en el menú desplegable del enum y añada un parámetro VI para especificar la distancia, las velocidades, etc. Si las unidades no coinciden, el comando VI es un gran lugar para mapear entre unidades.
A continuación, agregue código al controlador de unidad para definir qué sucede cuando se ejecuta el comando de unidad para distancia. Haga clic derecho en la estructura del caso y duplique o agregue caso para cada valor. Esto creará un nuevo caso «Drive for Distance».
Para acceder a nuevos campos de puntos de ajuste, haga crecer el nodo de deshacer «Puntos de ajuste de Cmd de acceso». Abra su codificador (o codificadores) en el exterior, a la izquierda del bucle. En el nuevo diagrama de la estructura del caso, agregamos una llamada para restablecer el codificador en la primera iteración del bucle y leerlo de otra manera. También hay un código simple que compara los valores del codificador y actualiza la potencia del motor. Si se agregan nuevos controles al grupo de puntos de ajuste, también debe considerar agregarlos al Trace. Los cambios necesarios se muestran en la imagen a continuación.
Parte 5: Creando un Subsistema
Para crear un nuevo subsistema, haga clic con el botón derecho del ratón en el objetivo de roboRIO y seleccione New» Subsystem. En el cuadro de diálogo emergente, introduzca el nombre del subsistema, enumere los modos de funcionamiento y especifique el color del icono.
Cuando haga clic en OK, la carpeta del subsistema se generará y se añadirá a la carpeta y al árbol del disco del proyecto. Contendrá una implementación base de los VIs y controles que componen un subsistema. Una llamada al nuevo controlador se insertará en los VI de los subsistemas. El controlador VI se abrirá, listo para que usted añada I/O e implemente el código de estado de la máquina o del control. Los iconos de los VI generados utilizarán el color y el nombre proporcionados en el diálogo. El código generado usará typedefs para los campos de puntos de ajuste y operaciones.
A continuación se muestra el diagrama de bloques del subsistema recién creado. Este código se generará automáticamente cuando se cree el subsistema.
