Sobre isso: https://github.com/ThundeRatz/vss_simulation/blob/8db4829085f2700ca1255c4610759212b4e25ed2/scripts/usb_dongle.py#L14

Tava conversando com o @d-nery e aí ele falou algumas coisas sobre as dependências do script. Bom, primeiro seria necessário instalar python3-venv. Então seria necessário criar um ambiente virtual pra rodar o script, estando no diretório que está o script, fazendo:

python3 - m venv venv

O segundo venv, é o nome da pasta onde tudo do ambiente será guardado, ela tem que ir pro .gitignore.

Então é necessário "ativar" o ambiente virtual com:

source venv/bin/activate

Se estiver usando fish tem que usar o activate.fish.

Dá primeira vez é necessário instalar todos as dependências na mão com o pip, por exemplo:

pip install numpy

Isso vai instalar as dependências no seu ambiente virtual.

Fazendo pip freeze no terminal, você consegue ver as dependências do seu script. Então é possível guardar isso em um arquivo, por exemplo requirements.txt, esse arquivo tem que ir pro GitHub. Com esse arquivo é possível instalar facilmente todas as dependências com:

pip install -r requirements.txt

Para desativar o ambiente virtual é só fazer deactivate no terminal.

A vantagem de fazer isso é que se facilita a instalação de dependências do script e também mantém um registro de qual versão de cada dependência se está utilizando no projeto, isso é bom também porque se tiver uma atualização não compatível das dependências se sabe qual a versão que é compatível.

Pra quem não sabe, o python 2 foi oficialmente descontinuado no começo desse ano. O @d-nery deu a dica de como podemos atualizar os nossos scripts para python 3, usando esse guia como referência.

De certa forma essa é uma tarefa relacionada com a issue #1, dependendo da minha facilidade em resolver esse problema eu já emendo e faço o upgrade

[flood]
O ROS vai lançar uma nova versão em Maio/2020, então se pá que se eu enrolar o suficiente os próprios desenvolvedores do ROS vão resolver esse BO pra mim
[/flood]

Esses dias, abri o simulation_match e fiquei muito confuso quando percebi que as cores das laterais dos robôs não corresponderem com as cores do time, mas sim com a de um dos robôs.

Acho que seria bom mudar o verde da lateral para amarelo, e o vermelho para azul, ai fica mais fácil de entender o que ta acontecendo durante a partida.

Ao rodar a simulação na branch feature/camera e tentar gerar uma bagfile com todos os tópicos que estavam sendo publicados, ocorreu um problema com tópicos realcionados à câmera, aparentemente devido ao formato da imagem. O erro era mostrado pelo gazebo e não pelo rosbag, sendo o seguinte:

[ERROR] [1601755303.697558886, 24.779000000]: Compressed Depth Image Transport - Compression requires sing
le-channel 32bit-floating point or 16bit raw depth images (input format is: rgb8).                        

Tentei desabilitar a parte de compressão da imagem como é feito aqui, tentei mexer em alguns parâmetros que estavam disponíveis no servidor de parâmetros do ros e também tentei mudar o formato da imagem que era publicada pela câmera, mas nenhuma dessa coisas resolveu.

A única forma de "resolver" que encontrei foi excluindo os tópicos que se relacionavam a parte de compressão da imagem na hora de gerar a bagfile, fazendo do seuinte jeito:

rosbag record -a -x "(.*)/compressed(.*)"

Vou deixar a issue aqui pra deixar no banco de tarefas, é bem de boas, teria q refatorar o lanchfile de dar spawn de 1 robô pra usar o spawn_robots.py. Pra isso teria q mudar algumas coisinhas no spawn_robots.py pra ele suportar 1 robô só e pra isso ao invés de usar posições pré definidas, usar valores passados pelo usuário.

Criando essa issue pra registrar aqui pra gente fazer templates de issues e PRs pra ficar mais fácil de criar issues e PRs

Não sei exatamente se isso é um bug mesmo, mas só pra deixar aqui, eu fui testar algumas coisinhas usando o rqt_steering_topic, e percebi que tem uns omportamentos estranhos as vezes.

A primeira coisa foi esse balanço quando eu colocava só uma velocidade angular.

Ele fica balançando pra frente e pra tras, e fica travando as vezes.

Outra coisa que aconteceu bastante foi dele ficar bastante descontrolado e não consegui seguir nem de perto uma linha reta quando eu colocava uma velocidade linear.

Não sei, pra mim parece que é um problema no modelo que ta causando esses comportamentos, mas posso estar errado. Vocês perceberam algo assim também? Aqui acontece quase sempre algo do tipo.

O mais estranho é que não lembro desse tipo de coisa acontecer tão frequentemente quando a gente usava o nosso modelo mesmo, por isso acredito que esse seja o problema, mas não tenho certeza.

Falei isso em alguma PR pra não esquecer, mas achei melhor documentar numa issue, a parte de estrutura das pastas nos READMEs ficou incompleta depois que a gente adicionou umas coisas, então precisamos completar.

Renomear o projeto para TraveSim

Vou criar essa issue aqui pra gente ver isso depois de dar merge na PR #16.

Do jeito que tá agora, o script de controle com o teclado/joystick ficou pra só poder controlar no modo "diff drive", aí acho que seria legal a gente poder permitir os dois jeitos, porque usar esse script é uma forma básica da gente testar se as coisas tão andando certinho no simulador e não conseguir testar as coisas de um jeito fácil complica por exemplo revisar mudanças que afetem o modo "direct drive".

Do jeito que tá, por exemplo, se a gente tentar rodar esse comando:

roslaunch vss_simulation simulation_robot.launch twist_interface:=false keyboard:=true

O simulador não vai funcionar, porque tem opções que são exclusivas.

A gente já passa ali a opção se usa twist ou não, então daria pra só passar isso como argumento na hora de executar o script do keyboard ou algo do gênero.

O tutorial oficial do ROS pra criar modelos de simulação no Gazebo utiliza um pacote de controle dos motores chamado http://wiki.ros.org/diff_drive_controller.

A primeira versão da simulação do VSS usava o diff_drive_controller, pois foi desenvolvida seguindo o tutorial oficial do ROS. Esse controlador recebe uma msg do tipo Twist e realiza o acionamento dos motores do robô. Para o histórico do uso desse controlador, veja o histórico do arquivo de configuração diffdrive.yaml

A principal vantagem em controlar o robô dessa forma é a facilidade na documentação (uso no tutorial oficial do ROS) e a existência da ferramenta gráfica rqt_robot_steering que permite o controle da simulação pela interface do computador.

No entanto, esse controlador abstrai coisas demais, o nosso projeto retorna a velocidade das rodas, não a velocidade do robô em si, e o controlador se mostrou instável durante as simulações.

Versões futuras do projeto deverão utilizar duas instâncias do velocity_controllers, uma para cada motor do robô. Esse controlador recebe uma mensagem do tipo std_msgs/Float64 que representa a velocidade angular desejada para o motor.

No momento em que escrevo, a migração está parcialmente concluída, as dependências lógicas do diff_driver_controller ainda não foram totalmente removidas na simulação de um robô. Um script python ainda deve ser desenvolvido para transformar msgs do tipo Twist em duas msgs Float64 (cada uma representado a velocidade angular de um motor), de modo a ainda ser possível utilizar a ferramenta gráfica rqt_robot_steering.

A priori, serei eu, @FelipeGdM quem vai fazer isso. Se alguém demonstrar interesse, essa tarefa será prontamente terceirizada. Estou abrindo essa issue para fins de documentação.