27 de January de 2022

Volver a Codificación de robots, parte 2: La caja negra ética

[ad_1]

En los últimos días, comencé a codificar en serio. El primero en 20 años cuando estaba construyendo el software para BRL LinuxBots. (La codificación que hice hace seis meses realmente no cuenta, ya que solo escribí o modifiqué pequeños fragmentos de Python).

Mi proyecto de codificación es crear una caja negra ética (EBB) o más precisamente un módulo que se puede utilizar para integrar un software EBB en un robot. Conceptualmente, el EBB es muy simple, es un registrador de datos: el robot equivalente a un registrador de datos de vuelo para aeronaves o un registrador de datos de eventos para vehículos de motor. Hice eso con Marina Jirotka hace casi cinco años. todas Los robots (y las IA) deben estar equipados con un EBB de serie. Nuestro argumento es muy simple: sin un EBB, será más o menos imposible investigar accidentes robóticos o cuasi accidentes, y en un artículo reciente sobre investigación de accidentes robóticos, argumentamos que con el uso cada vez mayor de robots sociales, los accidentes son inevitables y necesita ser investigado.

Desarrollar y demostrar el EBB es una parte fundamental de nuestro proyecto RoboTIPS de 5 años financiado por EPSRC. Por eso es genial hacer una investigación práctica. Algo que no he hecho en un tiempo.

Aquí hay un diagrama de bloques que muestra el EBB y su relación con un controlador de robot.

Diagrama de caja del sensor, inteligencia artificial incorporada y datos de actuación registrados por la caja negra ética

Como se muestra aquí, los flujos de datos desde el controlador del robot al EBB son solo en una dirección. El EBB no puede ni debe interferir con el funcionamiento del robot. Codificar un EBB para un robot específico sería sencillo, pero me propuse un objetivo más difícil: un módulo EBB genérico (es decir, una biblioteca de funciones) que, con algunos ajustes inevitables, se aplicaría a cualquier robot. Y asumí el desafío adicional de programar en Python utilizando las habilidades del excelente curso en línea Codecademy Python 2.

Hay dos elementos del EBB que deben ajustarse para un robot en particular. La primera es la estructura de datos utilizada para obtener y almacenar los datos del sensor, el actuador y la decisión en el diagrama anterior. Aquí hay un ejemplo de mi primer intento en un marco EBB usando la estructura del diccionario de Python:

# Esta estructura de diccionario sirve como

# 1 Especificación del tipo de robot y cualquier campo de datos que

# está registrado para este robot, &

# 2 la estructura de datos con la que entregamos datos en vivo al EBB

# Creemos una especificación mínima para un robot ePuck para este modelo

epuckSpec = {

# El primer campo * siempre * identifica el tipo de robot más # Versión y número de serie

“Robot” :: [“ePuck”, “v1”, “SN123456”],

# El resto de campos son datos que registraremos.

# comenzando con los motores

# .. de los cuales el ePuck solo tiene 2: izquierda y derecha

“Motores” :: [0,0],

# luego 8 sensores infrarrojos

“IrSensors” :: [0,0,0,0,0,0,0,0],

# ..nota que el ePuck tiene más sensores: acelerómetro, cámara, etc.

# pero eso será suficiente por ahora

# nivel de batería de ePuck

“Nivel de bateria” :: [0],

# luego 1 código de decisión, es decir, qué está haciendo el robot ahora

# El significado de estos códigos es específico de ambos robots

# y la aplicación

“DecisionCode” :: [0]

}}

En cuanto a si un diccionario es la mejor manera de hacerlo, no estoy 100% seguro ya que soy nuevo en Python (cualquier pensamiento de Pythonists experimentados es bienvenido).

La idea es que todos los EBB de robots deben definir dicha estructura de datos. Todos deben contener el primer campo “Robot”que nombra el tipo de robot, su número de versión y el número de serie. Las palabras clave de un menú estándar deben usarse en los siguientes campos según sea necesario. Como se muestra en este ejemplo, cada palabra clave va seguida de una lista de valores de marcador de posición donde el número de valores en la lista refleja la especificación del robot real. El robot ePuck, por ejemplo, tiene 2 motores y 8 sensores de infrarrojos.

El último campo de la estructura de datos es “DecisionCode”. Los valores almacenados en este campo son específicos del robot y de la aplicación. Para el robot ePuck, estos pueden ser 1 = “Detener”, 2 = “Girar a la izquierda”, 3 = “Girar a la derecha”, etc. Podríamos agregar otro valor para un parámetro para que el robot pueda decidir, por ejemplo, girar 40 grados a la izquierda “DecisionCode” :: [2,40]. También podríamos agregar un campo ‘Razón’ que almacena el motivo general de la decisión como en “DecisionCode” :: [2,40,”avoid obstacle right”] Tenga en cuenta que el campo de decisión puede ser una cadena como se muestra aquí o un código numérico.

Espero haber demostrado aquí que el diseño de esta estructura de datos y sus campos está en el corazón del EBB.

El segundo elemento de la biblioteca EBB que debe escribirse para el robot y la aplicación en particular es la función que obtiene los datos del robot.

# Obtenga datos del robot y guárdelos en la especificación de la estructura de datos

def getRobotData(Especificaciones):

La forma en que se implementa esta función varía mucho entre robots y aplicaciones de robots. Con nuestros ePucks mejorados para Linux con conexiones WiFi, esto probablemente se haga a través de un cliente-servidor TCP / IP, con el servidor ejecutándose en el robot y enviando datos a petición del cliente. getRobotData(ePuckspec). Para configuraciones más simples donde el módulo EBB se pliega en el controlador del robot y luego se accede a los datos requeridos getRobotData() debería ser muy fácil.

La parte genérica del módulo EBB define la clase EBB con métodos para inicializar el EBB y para almacenar un nuevo registro de datos en el EBB. Cubriré eso en otra publicación de blog.

Antes de concluir, permítanme agregar que tenemos la intención de publicar la especificación EBB junto con el código del modelo EBB como código abierto después de una revisión completa.

Cualquier comentario o retroalimentación será muy apreciado.


Enlace al artículo original aquí.

Alan Winfield

Autor invitado

Alan Winfield es profesor de robótica en UWE Bristol. Comunica sobre ciencia en su blog personal.

[ad_2]