Novembro 2019 – Robots RosPiBot
Estudo exploratório da interação homem máquina em linguagem natural no contexto visual
Pequeno relatório do estudo exploratório da interacção homem máquina em linguagem natural no contexto visual que efectuei com base num conjunto de processos ilustrados com as respectivas relações no diagrama mais abaixo.
Este abordagem à interacção homem máquina em linguagem natural tendo em conta o contexto visual da máquina, foi efectuada com o propósito de integrar o conhecimento adquirido num projecto de controlo vocal de um braço robótico Niryo One.
A solução que montei para explorar esta área está próxima do end user. Foi efectuada com o base no ROS e nos serviços do google cloud, e deste modo os principais serviços são caixas negras. Esta abordagem serve as minhas necessidades de aplicação prática já que não procuro saber como funcionam os processos mais complexos.
No entanto, alguns dos serviços remotos podem ser substituídos por soluções locais, dos quais destaco o reconhecimento de objectos e faces construídas com base no opencv e tensorflow. Uma segmentação dos custos de utilização dos serviços do google que exibo mais abaixo, sugere que serão os processos com o maior beneficio económico na execução local.
Os nodes ROS usados no projecto estão contidos no opencv_apps e no meta-pacote gc_bridge, que foi adoptado de um dos vários projectos que usei para compor esta exploração.
O pacote opencv_apps contêm os nodes locais que usei para explorar esta área. A exploração dos serviços de detecção facial do google tem de ser complementada por um node que republique a informação do rectângulo no node de reconhecimento facial no opencv. (TODO. colocar no repositório)
O gc_bridge contêm vários pacotes que contribuem em conjunto com outros que surgem como dependências do projecto.
gc_msgs
gc_dialogflow_bridge
gc_speech_bridge
gc_vision_bridge
Diagrama de relações entre os vários sistemas e mensagens envolvidas
gc_bridge
Meta pacote copiado do gc_bridge (https://github.com/jihoonl/gc_bridge), e ao qual foi adicionado posteriormente os outros pacotes. De origem o gc_bridge contribuiu com o gc_msgs e o gc_vision_bridge.
Este pacote contém a definição das mensagens trocadas com o serviço que processa a interacção com os serviços de análise de imagem do google.
As mensagens definidas neste pacote são usadas pelos nodes e serviços do gc_vision_bridge.
gc_dialogflow_brigde
Foi adaptado do pacote dialogflow_ros (https://github.com/piraka9011/dialogflow_ros). Contém o interface com o Google dialogflow services alimentado em tempo real pelo microfone, via transcrição de voz para texto, e o seu resultado alimenta o sistema de transcrição de texto para voz. O resultado dos serviços do dialogflow é construído tendo em conta a informação existente num servidor de contexto remoto, alimentado pelo os nodes do gc_vision_bridge.
Este pacote contem o software que processa as imagens recolhidas pelo node usb_cam, e as redirige para os nodes especializados de análise, armazenando num servidor remoto as respostas de cada um deles.
Este pacote foi adaptado do pacote speech_database (http://wiki.ros.org/speech_database)
Este pacote passou a incluir o node speech2text_mic.py que foi obtido no pacote (dialogflow_ros)
Nesta fase exploratória o leque de entendimento que se expressa no conjunto de comandos implementados visa apenas aspectos descritivos e de focalização de atenção.
Enunciar os objectos que detecta nas imagem da camera de video
Confirmar que está a ver um objecto
Indicar quantos objectos é que está a ver de um tipo especifico
Solicitação para ignorar determinados objectos
Solicitação para parar de ignorar objectos previamente ignorados
Saudar o utilizador
Autor adminPublicado em 19 Novembro, 2019 11 Dezembro, 2019 Categorias Geral
ROS roscore service
Instruções para correr o ROS roscore como serviço
Para o efeito é necessário criar dois ficheiros novos:
/etc/systemd/system/roscore.service
/etc/roscore_env.sh
Seguidamente usar o comando systemctl para testar o serviço e a sua activação posterior.
Criar o ficheiro para a unit roscore.service
sudo nano /etc/systemd/system/roscore.service
Substituir "kinetic" por "melodic" ou outra distribuição do ROS, na linha que começa por "ExecStart="
Substituir "ubuntu" pelo user adequado na linha User=ubuntu
After=NetworkManager.service time-sync.target
# Start roscore as a fork and then wait for the tcp port to be opened
# Source all the environment variables, start roscore in a fork
# Since the service type is forking, systemd doesn't mark it as
# 'started' until the original process exits, so we have the
# non-forked shell wait until it can connect to the tcp opened by
# roscore, and then exit, preventing conflicts with dependant services
ExecStart=/bin/sh -c ". /opt/ros/kinetic/setup.sh; . /etc/roscore_env.sh; roscore & while ! echo exit | nc localhost  11311 > /dev/null; do sleep 1; done"
Criar o ficheiro com as variáveis de ambiente para o roscore
sudo nano /etc/roscore_env.sh
Colocar o seguinte texto.
export ROS_HOSTNAME=$(hostname).local
Após criar estes ficheiros passamos a fase de teste.
Teste e conclusão da configuração do serviço roscore
Para testar iniciamos o serviço e seguidamente consultamos o seu estado com os seguintes comandos:
systemctl start roscore
systemctl status roscore
Se existir algum erro verificar se o texto foi bem copiado e as substituições bem feitas. Repetir a verificação até funcionar bem.