DRONE CON LEGO RASPBERRY PI Y JAVA PARTE 2 EL

DRONE CON LEGO RASPBERRY PI Y JAVA PARTE 2 EL

DRONE CON LEGO
RASPBERRY PI Y JAVA
PARTE 2
EL SOFTWARE
NOVIEMBRE 2013
Versión 1
1 INDICE
1
2
INDICE ............................................................................................................................................ 2
INTRODUCCIÓN .............................................................................................................................. 3
2.1
OBJETIVOS Y ALCANCE DEL PRESENTE DOCUMENTO .................................................................... 3
3
ADAPTACIÓN A MODELO DE DESPLIEGUE SOFIA2 .......................................................................... 4
4
ACCESO A LA PLATAFORMA ........................................................................................................... 5
5
ONTOLOGIAS.................................................................................................................................. 7
6
KPS ............................................................................................................................................... 13
7
CLIENTE REMOTO ......................................................................................................................... 16
8
RECEPTOR DRONE ........................................................................................................................ 17
JPIDron SOFIA2
Página 2/19
2 INTRODUCCIÓN
2.1
Objetivos y alcance del presente documento
El presente documento pretende describir el proceso de adaptación del Drone JPiDrone a la plataforma
SOFIA2. Convirtiendo las aplicaciones previas en KPs, desarrollando las ontologías para la comunicación
de información, así como realizando todos los pasos administrativos sobre un despliegue de la
plataforma.
JPIDron SOFIA2
Página 3/19
3 Adaptación a modelo de despliegue SOFIA2
JPIDrone consta de dos aplicaciones:
 Controlador del Dron: Aplicación Java ejecutándose en Raspberry Pi que recibe comandos de
actuación y los convierte en señales sobre los actuadores (servos y motores) del Dron.
 Joystick del Dron: Aplicación HTML/Javascript que envía comandos al Dron.
En el modelo de despliegue SOFIA estas aplicaciones se convierten en dos KPs
 Controlador del Dron  KP_Dron_Controller. Seguirá siendo una aplicación JAVA, que:
o Sustituirá su protocolo de comandado original por ontologías JSON
o Abstraerá su protocolo de comunicación original con el API JAVA de SOFIA2

Joystick del Dron  KP_Dron_Joystick. Será una aplicación HTML/Javascript que:
o Sustituirá su protocolo de comandado original por ontologías JSON
o Abstraerá su protocolo de comunicación original con el API JAVA de SOFIA2.
JPIDron SOFIA2
Página 4/19
4 Acceso a la plataforma
Una vez identificados los KPs a desarrollar, el siguiente paso es solicitar acceso a la plataforma.
Para ello vamos a http://scfront.cloudapp.net/ y en la sección Consola web seleccionamos Conexión
con el SIB-admin:
Esto nos redirige a la pantalla de Login, donde podremos solicitar un nuevo usuario:
Rellenamos el formulario con los siguientes datos:
JPIDron SOFIA2
Página 5/19
La password elegida es: leg0dr0n (con cero en vez de O)
Una vez registrados, nos aparecerá la siguiente pantalla, junto con el contacto al que solicitar nuestra
promoción a un usuario con rol Colaborador:
JPIDron SOFIA2
Página 6/19
5 Ontologias
La información enviada desde el Joystick hacia el controlador del Dron tiene la siguiente forma:

Comandado de la cámara: Consta de dos mensajes
o
o

Comandado de motores: Consta de un mensaje
o

{cameraYaw: xxx}
{cameraPitch: xxx}
{motorLeft:xx,motorRight:xx}
Comandado de stream de camara: Consta de un mensaje
o
{ streamHost:xxx.xxx.xxx.xxx, streamPort:xxxx, streamComando:START|STOP}
Todos los atributos de los mensajes enviados son de tipo double a excepción de streamHost (String) y
streamComando (constante START o STOP).
Esta es la información que debe tener la ontología de comandado del Dron.
Para desarrollar las ontologías partimos siempre de una plantilla de ontología. Las plantillas de
ontología existen en la plataforma y recogen una serie de campos mínimos que debe tener una
ontología.
Una vez tengamos rol Colaborador, desde Gestión de ontologías -> Crear ontologia podemos ver los
campos que cada una de las plantillas de ontología disponibles nos añaden:
JPIDron SOFIA2
Página 7/19
Examinando las diferentes plantillas ofrecidas, comprobamos que la plantilla Request encaja
perfectamente con nuestras necesidades.
De hecho Request es la plantilla base para las ontologías de comando
El esquema de la plantilla de ontología Request es el siguiente:
{
"$schema": "http://json-schema.org/draft-03/schema#",
"title": "PlantillaRequest Schema",
"type": "object",
"properties": {
"Request": {
"type": "string",
"$ref": "#/datos"
}
},
"datos": {
"description": "Info Plantila Requet",
"type": "object",
"properties": {
"timestamp": {
"type": "integer",
JPIDron SOFIA2
Página 8/19
"minimum": 0,
"required": true
},
"assetId": {
"type": "string",
"required": true
},
"targetKpInstance": {
"type": "string",
"required": true
},
"requestId": {
"type": "string",
"required": true
},
"request": {
"type": "string",
"required": true
}
}
}
}
La interpretación que hacemos de los campos es la siguiente:
 timestamp: Momento en el que envia el comando.
 assetId: Identificador del asset (Dron en nuestro caso) al que va dirigido el comando
 targetKpInstance: Instancia de KP al que va dirigido el comando.
 requestId: Identificador del comando.
 request: Datos del comando.
Por lo que daremos de alta tres ontologías con esta estructura:
 DronCameraCommand: No campos de extensión a la plantilla base Request, ya que será en el
campo request donde metamos los datos para el comandado ({cameraYaw: xxx} y
{cameraPitch: xxx})
JPIDron SOFIA2
Página 9/19

DronMovementCommand: No añade campos de extensión a la plantilla base Requestr, ya que
será en el campo request donde metamos los datos para el comandado
({motorLeft:xx,motorRight:xx})
JPIDron SOFIA2
Página 10/19
Y por último
 DronStreamCommand: No añade campos de extensión a la plantilla base Requestr, ya que será
en el campo request donde metamos los datos para el comandado ({
streamHost:xxx.xxx.xxx.xxx, streamPort:xxxx, streamComando:START|STOP}))
JPIDron SOFIA2
Página 11/19
JPIDron SOFIA2
Página 12/19
6 KPs
A continuación crearemos los KPs que identificamos en la adaptación al modelo SOFIA.
Para ello, los damos de alta en la plataforma desde Gestión KPs  Crear nuevo KP:

KP_Drone_Controller:
Como vemos en la imagen, seleccionamos las tres ontologías que dimos de alta en el paso anterior.

KP_Drone_Joystick:
JPIDron SOFIA2
Página 13/19
Como vemos en la imagen, seleccionamos las ontologías que dimos de alta en el paso anterior.
Una vez dados de alta, lo siguiente es generar los token de autenticación de ambos KPs y que
deberemos enviar a la plataforma en el mensaje JOIN.
Para ello vamos a Gestion KPs  Gestion de Tokens
Ahí aparecen nuestros KPs:
Seleccionandolos en la tabla de KPs les podemos generar y activar los Tokens:
JPIDron SOFIA2
Página 14/19
JPIDron SOFIA2
Página 15/19
7 Cliente Remoto
El lenguaje del cliente de envío de infromación a los KP es Javascript.
Los ficheros javascript necesarios para su
utilización.
JPIDron SOFIA2
Página 16/19
8 Receptor Drone
JPIDron SOFIA2
Página 17/19
JPIDron SOFIA2
Página 18/19
JPIDron SOFIA2
Página 19/19