ROS piraka9011 dialogflow_ros

Este pacote integra os serviços de linguagem natural do google nos robots com ROS.

A versão do pacote para o ROS piraka9011 dialogflow_ros necessita de ser compilada/instalada das fontes.

As fontes do pacote, e respectivas instruções estão disponiveis na informação oficial sobre o pacote no seguinte link:

https://wiki.ros.org/dialogflow_ros

As fontes estão disponiveis em:

https://github.com/piraka9011/dialogflow_ros

A exploração deste modulo implica o acesso a uma conta do google cloud.

Para a criação de uma conta e respectivo acesso consultar o seguinte link:

Autenticação no Google Cloud

A finalidade deste processo é preparar o projecto no gcloud assim como criar e obter um ficheiro de autenticação .json.

Quando o gcloud estiver instalado e iniciado pode-se dar inicio a exploração do pacote.

 

Exploração do pacote do ros dialogflow_ros

Após a preparação do ambiente do google cloud dediquei-me a instalar o modulo conforme indicado.

cd ~/catkin_ws/src
git clone https://github.com/piraka9011/dialogflow_ros.git
cd dialogflow_ros
pip install -r requirements.txt

A estes passos indicados na documentação é necessário também efectuar os passos seguintes que compilam o pacote no sistema, e é neessário por causa das mensagens definidas pelo pacote.

cd ~/catkin_ws
catkin_make

Seguidamente activa-se a conta adequada, incluindo o export.

export GOOGLE_APPLICATION_CREDENTIALS='/home/user/name.json'
gcloud auth activate-service-account --key-file $GOOGLE_APPLICATION_CREDENTIALS

Por ultimo modifiquei os ficheiros yaml conforme indicação da documentação de forma a acrescentar o id do projecto no google cloud.

Após esta preparação está-se então pronto para executar o ficheiro launch indicado na documentação.

roslaunch dialogflow_ros dialogflow.launch

A primeira execução nao deu som e apresentou os seguintes erros de relevo.

ALSA lib pcm_dmix.c:1052:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_dmix.c:1052:(snd_pcm_dmix_open) unable to open slave

Segundo esta página, que vêm referenciada no final da documentação do pacote, temos que instalar o jackd2 e reconfigurar o alsa.conf.

Nota: mais tarde duvidei da necessidade desta reconfiguração e instalação do jackd2.

Executei as duas e não funcionou. Decidi rebotar. Após o reboot, já nao corri o jackd -d alsa.

No entanto como me esqueci de exportar o caminho para o ficheiro de autenticação, o node morreu com a seguinte mensagem:

raise exceptions.DefaultCredentialsError(_HELP_MESSAGE)
google.auth.exceptions.DefaultCredentialsError: Could not automatically determine credentials. Please set GOOGLE_APPLICATION_CREDENTIALS or explicitly create credentials and re-run the application. For more information, please see https://cloud.google.com/docs/authentication/getting-started

Pelo que percebi pelo menos o export na shell tem de ser executado antes de correr o ficheiro de lançamento.

export GOOGLE_APPLICATION_CREDENTIALS='/home/user/name.json'

Relembro que o export pode ser colocado no ~/.bashrc

O node voltou a correr, com novos avisos, mas nada aconteceu na mesma.

Uma releitura da documentação do node acompanhada por uma vistoria aos ficheiros launch e scripts python disponiveis fez-me concluir que nunca funcionou como previsto pois nunca foi alimentado pelo microfone.

Provavelmente  não seria necessario a reconfiguração do alsa.conf, nem a instalação do jackd2.

Nesta linha executei script mic_client.py com o seguinte comando:

rosrun dialogflow_ros mic_client.py

O node executou, com o output que está como apendice 2, e do qual destaco o resultado da conversão de fala para texto efectuada pelo google cloud.

[INFO] [1572742147.231729]: Google Speech result: alternatives {
transcript: “my name is Sergio”
confidence: 0.921152949333
}
is_final: true
result_end_time {
seconds: 52
nanos: 140000000
}

A observação das transcrições não me deixou muito contente. Muitos erros. Apesar de já ter usado no passado esta solução num ivr de uma central telefónica não me recordava de ser tão mau o resultado.

No entanto também não efectuei configuração nenhuma especial para indicar o idioma pelo que só experimentei com o meu inglês macarrónico.

Por outro lado, não percebi bem qual a intensidade do som que inicia o processo de transcrição, nem a que finaliza. Já que ao fim de algum tempo, mesmo sem que eu fala-se o node morreu com a seguinte indicação:

google.api_core.exceptions.OutOfRange: 400 Exceeded maximum allowed stream duration of 305 seconds.

Aparentemente esteve a enviar o fluxo de audio durante 5 minutos sem que eu me apercebe-se.

Entretanto uma verificação rápida das ultimas mensagens chamou-me atenção para a seguinte transcrição:

Google Speech result: alternatives {
transcript: ” City sounds”
confidence: 0.85884976387
}

Não sendo uma transcrição de qualquer verbalização é no entanto descritiva do ambiente sonoro nesse periodo. Sons de cidade.

Esta situação leva-me a pensar que o ganho do micro deve ser ajustado no painel de controlo para um valor menor.

Mas, voltando ao tema inicial. O node lançado com o ficheiro launch (dialogflow_client.py) continuava sem publicar qualquer mensagem no seu topico de saida.

Uma verificação dos topicos publicados permitiu-me concluir que:

O node mic_client.py publicava no topico /dialogflow_text [std_msgs/String]

Enquanto que o dialogflow_client.py subscreve vários nodes, mas nenhum deles é esse.

As subscrições deste node são as seguintes:

/dialogflow_client/requests/df_event [unknown type]
/dialogflow_client/requests/df_msg [unknown type]
/dialogflow_client/requests/string_event [unknown type]
/dialogflow_client/requests/string_msg [unknown type]

O resultado deste node é publicado no seguinte topico.

/dialogflow_client/results [dialogflow_ros/DialogflowResult]

A indicação do [unknown type] também não permite avaliar em qual deles devemos publicar.

Para o mic_client a documentação indica:

ROS node receives text from the Google Cloud Speech API and publishes it onto text_topic (see config/params.yaml). This is used by the dialogflow_client node.

De seguida descreve o topico publicado.

Daqui supõe-se que o node dialogflow_client susbcreveria este topico.

Para o dialogflow_client a documentação indica:

ROS node that takes text from the mic_client node and sends it to Dialogflow for parsing.

Daqui supõe-se também que o node dialogflow_client susbcreveria este topico.

De seguida descreve o topico publicado. Mas sem qualquer referencia ao topico subscrito.

Dai a pergunta. Como vai o node dialogflow_client buscar o texto obtido pelo mic_client?

Pela observação do código parece que vai buscar o audio usando o pyaudio.

Estranho.

Também encontrei alguma informação conceptual sobre o a versão do piraka9011 do dialogflow_ros no seguinte link.

https://www.abouallaban.info/portfolio/ros-df