Feature/diff drive

[FelipeGdM]

Saudações amantes do mundo da bola,

Nessa atualização, o @Berbardo e eu trocamos o meio de controle dos robôs. Ao invés de receber comandos independentes pra cada uma das rodas, agora a simulação recebe um comando único do tipo Twist com os valores de velocidade linear e velocidade angular do robô

Os parâmetros do controlador são especificados no arquivo motor_diff_drive.yml (referência de parâmetros disponíveis) e foram calculados para um motor Pololu 6V 100:1 referência

No mais, fiquem bem e mantenham-se hidratados

[Berbardo]

Os parâmetros do controlador são especificados no arquivo motor_diff_drive.yml (referência de parâmetros disponíveis) e foram calculados para um motor Pololu 6V 100:1 referência

Acho que o motor é esse Pololu 6V 75:1 (em overvolt).

Não vou aprovar nem nada ainda porque acho melhor dar uma confirmada nas contas dos parâmetros antes.

[LucasHaug]

Os parâmetros do controlador são especificados no arquivo motor_diff_drive.yml (referência de parâmetros disponíveis) e foram calculados para um motor Pololu 6V 100:1 referência

Acho que o motor é esse Pololu 6V 75:1 (em overvolt).

Não vou aprovar nem nada ainda porque acho melhor dar uma confirmada nas contas dos parâmetros antes.

Eh, atualmente é 75:1 mesmo, mas aí como os motores que a gente vai comprar são 100:1, mesmo que a gente não tenha eles ainda, acho de boas deixar 100:1.

[Berbardo]

Eh, atualmente é 75:1 mesmo, mas aí como os motores que a gente vai comprar são 100:1, mesmo que a gente não tenha eles ainda, acho de boas deixar 100:1.

É que as contas foram feitas com o 75:1, aí faria sentido se a gente atualizar as contas tbm

[d-nery]

Eh, atualmente é 75:1 mesmo, mas aí como os motores que a gente vai comprar são 100:1, mesmo que a gente não tenha eles ainda, acho de boas deixar 100:1.

É que as contas foram feitas com o 75:1, aí faria sentido se a gente atualizar as contas tbm

Não sei exatamente do que estão falando ou como está feito, mas coisas baseadas em contas não deviam ser feitas na hora? Aqui deveria ter só o que for parâmetro base, o que é derivado a partir de contas devia ser gerado

[FelipeGdM]

Sobre o que foi comentado anteriormente da redução e tals, pra que exatamente serve o motor.xacro? Tipo, lá tem um parâmetro para a redução mecânica, que a gente sempre coloca como 1, sendo que na vdd não é 1 hahhahahha. Teria como usar isso para alguma coisa? E pra mim o modelo do motor agora teria sido abstraído pelo diff_drive_controller. Faz sentido ele ainda existir?

@lucastrschneider excelente colocação aqui. Vamos por partes, vou responder as perguntas de trás pra frente.

Faz sentido ele ainda existir?

Sim, ele é essencial pro funcionamento do simulador

Teria como usar o fator de redução pra alguma coisa?

Sim, esse pârametro tem sua utilidade. As joints possuem um conjunto de parâmetros de limites de operação, que ficam dentro da tag <limit> (não confundir com limites de segurança, que ficam na tag <safety_controller>). A ideia é definir o limite de esforço que pode ser realizado pela junção e impedir que o motor faça mais força ou gire mais rápido do que realmente consegue. A função da tag <mechanicalReduction> é calcular os esforços (torque e velocidade) no eixo do motor, antes de passar pra redução, de forma que os atributos de limite definidos do modelo podem ser generalizados pro motor sem a caixa de redução, como descrito aqui. No nosso caso, a gente poderia colocar na descrição do nosso robô os parâmetros de um micromotor Pololu 6V, sem se preocupar com a taxa de redução e especificar a taxa de redução propriamente no motor.xacro.

É algo interessante de ir atrás, eu nunca tive interesse nisso exatamente, ~tinha até esquecido, na real~

Pra que exatamente serve o motor.xacro?

Em linhas gerais, ele descreve a presença de um motor dentro do nosso modelo. Filosoficamente falando, é necessário que haja um motor a ser controlado para o controlador poder funcionar, não é mesmo? E como o próprio nome diz, tanto o diff_drive_controller quanto o velocity_controller são controladores, ou seja, eles trabalham em cima de um motor.

Espero que tenha dado pra entender a lógica por trás do motor.xacro, qualquer dúvida que tenha ficado, tamo aí

Tem ainda o config/joint_names_vss_robot.yaml que eu não consegui achar ele sendo carregado em nenhum lugar, então não sei se tem alguma coisa que usa ele escondido kkkkkkkkk

Entonces, filosoficamente falando, esse arquivo é realmente inútil e nunca foi efetivamente utilizado hue. Ele é gerado pelo SW2URDF e nunca foi removido, foi só ficando ali no canto dele. Concordo que já passou da hora de remover hahahahaha

Historicamente falando, o ros_control.so seco foi utilizado pois a referência original (tutorial top da ROS wiki) usava esse plugin de Gazebo. No tutorial, ele usa um monte de controlador diferente pra demostrar as diferentes possibilidades, mas a nossa aplicação é mais restrita e se aproxima mais do turtlebot. Nesse sentido, acredito que é interessante sim fazer essa troca, pras coisas ficarem o mais específicas e auto explicativas possível.

Uma coisa que eu acho que seria interessante de fazer é pegar todos os parâmetros fisicos e juntar em um .yaml. Tipo, o thundervolt também precisa de algumas informações como velocidade maxima, distancia entre as rodas, raio das rodas, etc, na hora de mandar as mensagens por radiofrequência, e eu acho que seria mt melhor se todas essas infos estivessem centralizadas em um arquivo só

O motor_diff_drive.yaml já não cumpre essa função?

[FelipeGdM]

Salve salve amantes do mundo da bola

Depois de um longo e tenebroso inverno, cá estou novamente para podermos fechar essa PR

Tendo em vista nos aproximarmos da interface do FiraSim, a interface de controle direto da velocidade dos motores foi restaurada e agora temos suporte a duas interfaces de controle, controle de direção diferencial (vel. linear; vel. angular) e controle direto dos motores (vel. motor esquerdo; vel. motor direito). É possível selecionar qual interface será utilizada por meio do parâmetro twist_interface

Sobre os parâmetros dinâmicos dos motores, eu percebi que cometemos um erro de conta ao calcular a aceleração angular máxima (usamos massa*raio² ao invés do momento de inércia calculado no CAD), de modo que os valores mudaram um pouco. Como o modelo genérico não está nada relacionado com o projeto do ThunderVolt, eu mudei a referência para um motor sem overvolt pra facilitar as contas, então utilizei um Pololu 50:1 como referência. Os valores e as contas efetuadas se encontram no README do modelo.

No mais, essas foram as principais mudanças realizadas desde as últimas revisões, acredito que agora está tudo certo

Fiquem bem e mantenham-se hidratados

[lucastrschneider]

A few months later

Uma coisa que eu acho que seria interessante de fazer é pegar todos os parâmetros fisicos e juntar em um .yaml. Tipo, o thundervolt também precisa de algumas informações como velocidade maxima, distancia entre as rodas, raio das rodas, etc, na hora de mandar as mensagens por radiofrequência, e eu acho que seria mt melhor se todas essas infos estivessem centralizadas em um arquivo só

O motor_diff_drive.yaml já não cumpre essa função?

Cumpre, porém ele existe no contexto da simulação. Tipo, faz sentido isso estar definido aqui para o robô de VSS genérico. Mas e quando a gente tiver rodando o Thundervolt la na competição? Tipo, o Transmitter atual usa esses parâmetros também, mas não os gerais de um robô qualquer, e sim os do nosso projeto. Para mim, o arquivo .yaml de cofiguração de parâmetros físicos deveria ficar no repo do thundervolt, de forma que eles sejam carregados la para o parameter server. Para simular, temos o repo do thundervolt_simulation que seria responsável por dizer para o vss_simulation que a gente quer usar aqueles parâmetros, e não os genéricos. Mas para isso acontecer, o vss_simulation tem que estar preparado para fazer isso.

Além disso, agora temos dois .yaml para os plugins né, então o motor_diff_drive.yaml enm sempre é carregado.

Não sei se ficou muito claro o que eu quis dizer, nem se faz sentido no contexto dessa PR, mas qualquer coisa me lembra que a gente discute melhor em reunião.

~Agora eu vou la revisar os commits de vdd~

[FelipeGdM]

@lucastrschneider

Cumpre, porém ele existe no contexto da simulação. Tipo, faz sentido isso estar definido aqui para o robô de VSS genérico. Mas e quando a gente tiver rodando o Thundervolt la na competição? Tipo, o Transmitter atual usa esses parâmetros também, mas não os gerais de um robô qualquer, e sim os do nosso projeto. Para mim, o arquivo .yaml de cofiguração de parâmetros físicos deveria ficar no repo do thundervolt, de forma que eles sejam carregados la para o parameter server. Para simular, temos o repo do thundervolt_simulation que seria responsável por dizer para o vss_simulation que a gente quer usar aqueles parâmetros, e não os genéricos. Mas para isso acontecer, o vss_simulation tem que estar preparado para fazer isso.

Certo, entendi o que vc disse. Tenho algumas considerações a fazer, bora lá

Em competição, todos os times usam o mesmo modelo de robô na simulação, da mesma forma de quando usam o FiraSim. É uma questão de isonomia, né? Então em termos de competições virtuais, não existe a preocupação com o modelo virtual do ThunderVolt, uma vez que ele não será utilizado em competição, certo?

Dito isso, concordo com vc que é interessante ter uma interface no ambiente de simulação que permita a utilização de parâmetros customizados. Acredito que é algo simples de ser feito, basta colocar um if "os parâmetros já existem?" ao redor do load, de modo que se você carregar os parâmetros antes de chamar o launchfile do simulador, os seus parâmetros não serão sobrescritos.

Lembrando que a feature "carregar modelos customizados" não se aplica ao contexto de competição

Além disso, agora temos dois .yaml para os plugins né, então o motor_diff_drive.yaml nem sempre é carregado.

Positivo. No final das contas, o comportamento é exatamente o mesmo. só muda a interface de controle. No entanto, é importante notar que no caso do controlador direto, as propriedades dos motores são herdadas diretamente do arquivo .urdf, ao passo que o controlador diferencial puxa as propriedades do arquivo .urdf E do arquivo .yml e faz valer a que for mais restritiva

Eu fui olhar novamente a documentação oficial do diff driver e acredito que o ideal seria desabilitar a limitação de velocidade no controlador e deixar os parâmetros do modelo definirem o comportamento do robô. Dessa forma, tanto no caso do controle diferencial ou no controle direto, o mecanismo de limitação da velocidade é o mesmo (os parâmetros da joint das rodas). De qualquer forma, os parâmetros dos motores e do modelo genérico continuam documentados no README dentro da pasta urdf

O que vcs acham?

[lucastrschneider]

Em competição, todos os times usam o mesmo modelo de robô na simulação, da mesma forma de quando usam o FiraSim. É uma questão de isonomia, né? Então em termos de competições virtuais, não existe a preocupação com o modelo virtual do ThunderVolt, uma vez que ele não será utilizado em competição, certo?

Sim sim, tudo que comentei foi pensando em um contexto de competições presenciais, por isso também não sabia se fazia sentido pensar nisso agora no contexto dessa PR, acho que da pra deixar mais para frente, mas pelo menos ta registrado em algum lugar kkkkkkkk

Eu fui olhar novamente a documentação oficial do diff driver e acredito que o ideal seria desabilitar a limitação de velocidade no controlador e deixar os parâmetros do modelo definirem o comportamento do robô. Dessa forma, tanto no caso do controle diferencial ou no controle direto, o mecanismo de limitação da velocidade é o mesmo (os parâmetros da joint das rodas). De qualquer forma, os parâmetros dos motores e do modelo genérico continuam documentados no README dentro da pasta urdf

O que vcs acham?

Eu gosto de deixar essa infos em um só lugar, fica bem mais organizado acho. Só tem que testar direitinho o diff drive sem as limitações de velocidade e aceleração para ver se as joints limitam mesmo e se ele funciona parecido com o controle direto