As descrições de comunicação a seguir foram adaptadas de Ardrone Open API Platform.
No post AR.Drone: VANT Para A Academia está descrito a modelagem dinâmica do AR.Drone e agora o foco será descrever como é realizada a comunicação de um computador ou dispositivo com o drone.
Basicamente, o drone dispõe de uma conexão sem fio 802.11b para enviar e receber strings em ASCII com a finalidade de comunicar-se com um dispositivo. Logo, mediante a essa comunicação, podemos obter os logs dos sensores, status da bateria e ainda dos dados das câmeras e é claro, enviar comandos de takeoff(decolagem), landing(pouso), Pitch(Movimentação para frente ou para trás), Roll(Movimentação para o lado esquerdo ou direito), Throttle(Para cima ou para baixo) e Yaw(Movimentação sobre o eixo Z). A comunicação, portanto é bem simples, vejamos uma melhor descrição durante essa seção.
1.1 – Conexão WiFi
O AR.Drone pode ser controlado por qualquer dispositivo que suporte WiFi em modo ad-hoc. Basicamente podemos citar os princípios da conexão em quatro passos:
- O drone cria uma rede WiFi para conexão com ESSID denominado ardrone_xxx, alocando um endereço de IP ao drone.
- Os dispositivos serão conectados ao drone mediante a essa rede com esse ESSID.
- O Drone possui um DHCP server para fornecer um endereço de IP válido ao dispositivo que se conectou ao drone.
- O servidor DHCP do drone garante que cada a cada dispositivo será associado um único endereço IP.
A partir desse momento o dispositivo poderá se comunicar com o drone mediante o envio de requisições através dessa conexão, tendo um endereço de IP e porta.
1.2 – Comunicação entre o AR.Drone e o dispositivo
O controle, bem como a configuração do drone, é realizado mediante o envio de comandos AT na porta UDP 5556. Os comandos podem ser enviados em uma base de tempo regular, geralmente 30 vezes por segundo. Informações e sintaxe dos comandos AT serão vistos na seção 1.3. Informações sobre o drone como, pro exemplo, posição status, velocidade, velocidade de rotação dos motores, conhecidos como navdata, sendo, portanto, enviadas do drone para ao cliente através de UDP pela porta 5554. Nesses navdata também estão inclusas informações de detecção de tags para games com o drone. Também, são enviados aproximadamente 30 vezes por segundo. O stream de vídeo é enviado pelo AR.Drone através da porta 5555. As imagens do vídeo podem ser decodificadas usando o codec incluso no SDK, Software Developer Kit. Um canal de comunicação, conhecido como control port, pode ser estabelecido na porta TCP 5559 para transferência de dados críticos, sendo utilizado para recuperar dados de configuração e ainda para reconhecer informações importantes como o envio de informações de configuração para o drone.
1.3 – Funções de controle do AR.Drone
Nessa seção descreveremos os principais comandos para realizar o total controle do drone. Será informado os comandos AT correspondentes juntamente com as suas descrições e argumentos.
1.3.1 – Modo de emergência
Comando AT correspondente: AT*REF
Args: ( int value: emergency flag )
Quando o drone está no estado normal, se usarmos o comando com o parâmetro value igual a 1 o drone entrará em envio de sinal de emergência, fazendo com que os motores parem e o VANT caia. Agora, caso ele já esteja em modo de emergência bastará usarmos value igual a 1 para que ele tente voltar ao estado normal. Para encerrarmos o envio do sinal de emergência será preciso antes verificar se o estado do drone realmente foi alterado para o estado de emergência e, caso sim, basta fazer value igual a 0 para interromper o envio do estado de emergência.
1.3.2 – Movimentos
Comando AT correspondente: AT*PCMD
int flags: Habilita o controle do drone
Args: (
- float phi: Ângulo direito e esquerdo [-1;1]
- float theta: Ângulo frontal e traseiro [-1;1]
- float gaz: Velocidade vertical [-1;1]
- float yaw: Velocidade angular [-1;1]
)
O drone, portanto, é controlado por quatro parâmetros:
- Ângulo direito e esquerdo: Valores positivos representando o movimento para a direita e os negativos para a esquerda.
- Ângulo frontal e traseiro: Valores positivos representando o movimento para trás e os negativos para a frente.
- Velocidade vertical: Representando o movimento de subida com os valores positivos e os de descida com valores negativos.
- Velocidade angular em torno do eixo YAW: Representa o movimento em torno do eixo Z, sendo, valores positivos representando o movimento para a esquerda e os negativos para a direita.
A função da flag é decidir se o drone estará em modo hover (piloto automático) ou se ele será controlado pelo usuário, sendo assim:
- Bit 0: drone em modo hover
- Bit 1: drone em modo controle
A tabela abaixo contém um resumo dos comandos AT.
Comando AT | Argumentos | Descrição |
---|---|---|
AT*REF | input | Takeoff/Landing/Comando de cessar envio de sinal de emergência |
AT*PCMD | flag, roll, pitch, throttle e yaw | Movimenta o drone |
AT*FTRIM | - | Configura o drone para se estabilizar no plano horizontal |
AT*CONFIG | key, value | Configuração do AR.Drone |
AT*LED | animação, frequência, duração | Sequência de animação dos leds |
AT*ANIM | animação e duração | Sequência de animação de voo do drone |
2 – Comandos AT
Os comandos AT são strings enviadas ao drone como verificamos na seção 1.
2.1 – Sintaxe
As strings são codificadas em caracteres ASCII de 8 bits com um delimitador <LF>, Line Feed. Ainda, cada comando é composto por três caracteres AT* seguidos pelo nome do comando e um sinal de igual, um número de sequência e, caso seja necessário, uma lista de argumentos separados por vírgula cujo significado dependerá do comando em questão. É possível enviar mais de um comando AT em pacotes UDP desde que sejam separados pelo delimitador <LF> mas um mesmo comando AT não poderá ser enviado em pacotes UDP separados.
Como exemplo, temos:
AT*PCMD=21625,1,0,0,0,0<LF>AT*REF=21626,290717696<LF>
É de extrema importância que o tamanho total do comando não ultrapasse 1024 bytes, isto é, 1024 caracteres, caso contrário toda a linha de comando será rejeitada. Para alterar o limite será necessário modificar o software interno do AR.Drone. Vale lembrar que comandos inválidos também serão rejeitados, entretanto é conveniente que o cliente envie comandos corretos em UDP.
2.2 – Comandos sequenciais
Com a finalidade de evitar a execução de comandos antigos, um número de sequência é associado a cada comando AT de modo que o drone não execute nenhum comando cujo número de sequência seja menor que o último executado por ele. O comando de sequência é o primeiro número depois do igual e a cada novo comando devemos incrementá-lo. A cada nova conexão o número de sequência será retrocedido para o valor 1 no drone. Logo é importante que se envie um comando em no mínimo a cada 2 segundos a fim de não perder a conexão entre o cliente e o drone.
Portanto, deve-se seguir as seguintes regras:
- Sempre enviar o valor 1 como o primeiro número de sequência ao drone.
- O valor de sequencia deverá ser crescente, ou seja, incrementado a cada novo comando enviado ao AR.Drone.
2.3 – Descrição dos comandos
A seguir será descrito cada comando aceito pelo AR.Drone de modo a obter total conhecimento e clareza no desenvolvimento de softwares de controle para o drone.
2.3.1 – AT*REF
Controla o comportamento básico do AR.Drone, isto é, os comandos de take-off, landing, emergency, stop e reset.
Sintaxe: AT*REF=%d,%d<LF>
- Argumento 1: O número de sequência
- Argumento 2: Um valor inteiro de 32b []
Exemplo: AT*REF=1,290718208<LF>AT*REF=2,290717696<LF>
Nesse exemplo, o primeiro comando aciona o take-off e o segundo o landing.
2.3.2 – AT*PCMD
Esse comando é responsável por fazer com que o drone se movimente.
Sintaxe: AT*PCMD=%d,%d,%d,%d,%d,%d<LF>
- Argumento 1: Número de sequência
- Argumento 2: Flag de controle do drone
- Argumento 3: Roll [-1;1]
- Argumento 4: Pitch [-1;1]
- Argumento 5: Throttle [-1;1]
- Argumento 6: Yaw [-1;1]
A função da flag é decidir se o drone estará em modo hover (piloto automático) ou se ele será controlado pelo usuário, sendo assim:
- Bit 0: drone em modo hover
- Bit 1: drone em modo controle
2.3.3 – AT*FTRIM
Este comando deve ser chamado toda vez que o drone entrar no estado de take-off para que ele possa se estabilizar em um plano horizontal automaticamente, logo ele ajustará automaticamente os movimentos de pitch e roll para que a estabilização esteja completa. Caso não utilize o FTRIM o drone poderá sofrer uma desestabilização no momento em que estiver decolando, não sabendo, portanto, a sua inclinação real.
Sintaxe: AT*FTRIM=%d<LF>
- Argumento 1: Número de sequência
2.3.4 – AT*CONFIG
Este comando é responsável por pré-ajustar as configurações padrões do drone como, por exemplo, o ajuste da altura máxima.
Sintaxe: AT*CONFIG=%d,%s,%s<LF>
- Argumento 1: Número de sequência
- Argumento 2: Nome da opção de configuração entre aspas duplas, vide lista de comandos 2.3.7
- Argumento 3: Valor da configuração, também entre aspas duplas
2.3.5 – AT*LED
Este comando é responsável por fazer com que os LEDs, Diodo Emissor de Luz, dos quatro motores pisquem em uma sequência definida.
Sintaxe: AT*LED=%d,%d,%d,%d<LF>
Argumento 1: Número de sequência
Argumento 2: Inteiro para iniciar a animação
Argumento 3: float, definindo a frequência, em Hz, da animação
Argumento 4: inteiro, duração total da animação, lembrando que a animação é executada da seguinte forma: duração x frequência da animação
2.3.6 – AT*ANIM
É responsável por executar movimentos pré-definidos.
Sintaxe: AT*ANIM=%d,%d,%d<LF>
- Argumento 1: Número de sequência
- Argumento 2: inteiro, definindo qual animação será executada
- Argumento 3: inteiro, definindo a duração total, em segundos, da animação
2.3.7 – Lista de configuração
Abaixo podemos verificar os parâmetros de configuração do drone.
GENERAL:num\_version\_config = 1
GENERAL:num\_version\_mb = 17
GENERAL:num\_version\_soft = 1.1.3
GENERAL:soft\_build\_date = 2010-08-06 09:48
GENERAL:motor1\_soft = 1.8
GENERAL:motor1\_hard = 3.0
GENERAL:motor1\_supplier = 1.1
GENERAL:motor2\_soft = 1.8
GENERAL:motor2\_hard = 3.0
GENERAL:motor2\_supplier = 1.1
GENERAL:motor3\_soft = 1.8
GENERAL:motor3\_hard = 3.0
GENERAL:motor3\_supplier = 1.1
GENERAL:motor4\_soft = 1.8
GENERAL:motor4\_hard = 3.0
GENERAL:motor4\_supplier = 1.1
GENERAL:ardrone\_name = My ARDrone
GENERAL:flying\_time = 1810
GENERAL:navdata\_demo = TRUE
GENERAL:com\_watchdog = 2
GENERAL:video\_enable = TRUE
GENERAL:vision\_enable = TRUE
GENERAL:vbat\_min = 9000
CONTROL:accs\_offset = { -2.2696499e+03 1.9345000e+03 1.9331300e+03 }
CONTROL:accs\_gains = { 9.6773100e-01 2.3794901e-02 7.7836603e-02 -1.2318300e-02
-9.8853302e-01 3.2103900e-02 7.2116204e-02 -5.6212399e-02 -9.8713100e-01 }
CONTROL:gyros\_offset = { 1.6633199e+03 1.6686300e+03 1.7021300e+03 }
CONTROL:gyros\_gains = { 6.9026551e-03 -6.9553638e-03 -3.8592720e-03 }
CONTROL:gyros110\_offset = { 1.6560601e+03 1.6829399e+03 }
CONTROL:gyros110\_gains = { 1.5283586e-03 -1.5365391e-03 }
CONTROL:gyro\_offset\_thr\_x = 4.0000000e+00
CONTROL:gyro\_offset\_thr\_y = 4.0000000e+00
CONTROL:gyro\_offset\_thr\_z = 5.0000000e-01
CONTROL:pwm\_ref\_gyros = 471
CONTROL:control\_level = 1
CONTROL:shield\_enable = 1
CONTROL:euler\_angle\_max = 3.8424200e-01
CONTROL:altitude\_max = 3000
CONTROL:altitude\_min = 50
CONTROL:control\_trim\_z = 0.0000000e+00
CONTROL:control\_iphone\_tilt = 3.4906584e-01
CONTROL:control\_vz\_max = 1.2744493e+03
CONTROL:control\_yaw = 3.1412079e+00
CONTROL:outdoor = TRUE
CONTROL:flight\_without\_shell = TRUE
CONTROL:brushless = TRUE
CONTROL:autonomous\_flight = FALSE
CONTROL:manual\_trim = FALSE
NETWORK:ssid\_single\_player = AR\_hw11\_sw113\_steph
NETWORK:ssid\_multi\_player = AR\_hw11\_sw113\_steph
NETWORK:infrastructure = TRUE
NETWORK:secure = FALSE
NETWORK:passkey =
NETWORK:navdata\_port = 5554
NETWORK:video\_port = 5555
NETWORK:at\_port = 5556
NETWORK:cmd\_port = 0
NETWORK:owner\_mac = 04:1E:64:66:21:3F
NETWORK:owner\_ip\_address = 0
NETWORK:local\_ip\_address = 0
NETWORK:broadcast\_address = 0
PIC:ultrasound\_freq = 8
PIC:ultrasound\_watchdog = 3
PIC:pic\_version = 100925495
VIDEO:camif\_fps = 15
VIDEO:camif\_buffers = 2
VIDEO:num\_trackers = 12
DETECT:enemy\_colors = 1
SYSLOG:output = 7
SYSLOG:max\_size = 102400
SYSLOG:nb\_files = 5
Referências:
One thought on “AR.Drone: Comunicação”