Projeto #329
AbertaMeta #271: Implementar correção de deslizamento no firmware
Estudar artigos sobre deslizamento
Arquivos
Atualizado por Onias Castelo Branco há quase 7 anos
- Arquivo matriz_roboime_omnirodas.m matriz_roboime_omnirodas.m adicionado
- Arquivo omnidrive_kiart_preprint.pdf omnidrive_kiart_preprint.pdf adicionado
- Arquivo omnidrive.pdf omnidrive.pdf adicionado
- Atribuído para ajustado para Sérgio Gabriel dos Santos Dias
O firmware atual tem, além da matriz que distribui as 3 velocidades do robô para as 4 rodas, uma proposta de correção para deslizamentos. Ela se basea no fato de que ao mover as quatro rodas, alguma delas pode não ter a velocidade pretendida, fazendo que o robô deslize (gaste bateria desnecessariamente, ter seu movimento total atrapalhado por uma roda etc). O cálculo colocado consiste em checar se há alguma componente das velocidades no espaço nulo da matriz de transformação Vel_robo->Vel_rodas.
A ideia dessa tarefa é checar esse código, compreender os dois e verificados se os modelos se estão corretos, implementar no robô e testar no mundo real. O código que está implementado no firmware (https://github.com/roboime/roboime-firmware/blob/robocup2017/src/control/Robo.cpp linhas 79 ate 105) não sabemos se funciona ou não (a tolerância que eu botei pode ter sido muito grande ou ele simplesmente não funciona, ou seja, tem que examinar e descobrir o que está acontecendo).
Anexos estão o .m q eu fiz um tempo atras pra fazer o modelo e os artigos que eu usei pra aprender.
Atualizado por Onias Castelo Branco há quase 7 anos
Capitão, eu não achei seu codigo no github, o sr ainda tem alguma versao do firmware com ele?
Atualizado por Luiz Renault Leite Rodrigues há quase 7 anos
Atualizado por João Guilherme Oliveira Carvalho de Melo há mais de 6 anos
- Arquivo firmware.PNG firmware.PNG adicionado
Analisando o código do matlab e o do firmware (que é baseado no do matlab), percebi alguns problemas:
1. A matriz de conversão das velocidades radial, tangente e rotacional do Matlab não bate com a conversão feita no firmware (que está, pois o robô funciona).
2. O critério utilizado no firmware para avaliar se a velocidade deve ser corrigida ou não (Linhas 89 a 93 do Robo.cpp) não é confiável pois não analisa a possibilidade de M1 ou M2 serem negativos e também não se sabe a partir de que valores de M1 e M2 o deslizamento passa a ter uma grandeza considerável.
3. A alteração das velocidades, no caso de deslizamento, também está baseada no código do Matlab, então também precisa ser corrigida.
Atualizado por João Guilherme Oliveira Carvalho de Melo há mais de 6 anos
- Arquivo matriz de conversao.PNG matriz de conversao.PNG adicionado
A matriz correta para conversão das velocidades é:
Assim, a matriz para análise da existência de deslizamento (I-DD+), onde D+ é a pseudo-inversa de D, fica:
A =
0.300000000000000 -0.244948974278318 -0.300000000000000 0.244948974278318
-0.244948974278318 0.200000000000000 0.244948974278318 -0.200000000000000
-0.300000000000000 0.244948974278318 0.300000000000000 -0.244948974278318
0.244948974278318 -0.200000000000000 -0.244948974278318 0.200000000000000
Ou seja, se (I-DD+)v=0 não há deslizamento, onde v é o vetor de velocidades das rodas.
Logo, os vetores de velocidade que não pertencerem ao espaço nulo da transformação linear I-DD+ devem ser alterados, assim, basta analisar se o vetor tem, ou não, componentes fora do espaço nulo da TL.
Para isso, calculou-se a base ortonormal de I-DD+:
u =
-0.547722557505166
0.447213595499958
0.547722557505166
-0.447213595499958
Caso o vetor de velocidades possua componentes sobre o vetor "u", ou seja, se o módulo da projeção de v em u for maior que zero, devemos alterar as velocidades.
Para considerar as imprecisões do sistema, podemos estipular um valor para o módulo da projeção de v em u à partir do qual o deslizamento passará a ser considerado e eliminado.
Módulo da projeção de v em u:
|Proj| = mod(-0,5477*v0+0,4472*v1+0,5477*v2-0,4472*v3)
Caso o deslizamento deva ser eliminado, a velocidade será alterada de acordo com a seguinte expressão:
v' = v-Proj(v,N(C_a)), onde:
- v é o vetor de velocidades;
- N(T) é o núcleo da transformação linear T;
- C_a é a matriz que converte as forças em acelerações;
C_a =
-0.707106781186547 0.500000000000000 -0.707106781186547 0.500000000000000
0.707106781186548 0.866025403784439 -0.707106781186548 -0.866025403784439
1.000000000000000 1.000000000000000 1.000000000000000 1.000000000000000
Se houver deslizamento e o vetor de velocidades possuir componentes no espaço nulo de C_a, essas componentes devem ser eliminadas, assim:
v' = v - (v,w)*w, onde w é a base ortonormal do kernel de C_a, já que seu espaço nulo tem dimensão 1.
w =
0.547722557505166
-0.447213595499958
-0.547722557505166
0.447213595499958
Atualizado por Onias Castelo Branco há mais de 6 anos
Os vídeos com as modificações mais recentes do firmware foram colocados no grupo do wpp e a alteração ja foi commitada na branch KickStrength. Foi corrigido o raio da velocidade angular de 9cm para 7.5cm. A avaliação geral é que houve uma melhora no movimento do robô.
Testamos também uma alteração a mais: Pegar a velocidade atual das rodas (vetor u) e o vetor de velocidades de rodas que o rodo recebe da inteligencia (m=Dv, onde v=[v_r v_t w]).
A ideia foi mandar para a classe motor a componente da velocidade da roda que está na direção de m: u = m<m,u>/<m,m>.
O resultado foi que o robô passou a se movimentar com muito mais força, perdendo mais o controle. Desligamos o robô e sentimos um cheiro de queimado. Checando as pontes h, vimos que estavam bem quentes. Retiramos essa alteração e substituimos o firmware pela versão anterior.
Sobre a analise do código que o cap colocou no github. Entendemos boa parte de sua lógica, porém não temos ctz se ela está correta. Pelo que vimos, ele diminui todas as velocidades do robô, exceto a que está mais lenta em relação ao enviado pela inteligência. Se for isso, podemos implementar durante o fds.
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
Colocar os videos na tarefa.
O desafio agora é fazer o robô movimentar em zig-zag sem alterar a direção.
O código para manter a direção é exatamente isso. Ele faz com que as rodas mais rápidas esperem as rodas mais lentas.
Atualizado por Onias Castelo Branco há mais de 5 anos
- Atribuído para excluído (
Sérgio Gabriel dos Santos Dias) - Versão excluído (
CBR 2017)
Atualizado por Onias Castelo Branco há mais de 5 anos
- Atribuído para ajustado para Vinicius Moraes
Atualizado por Onias Castelo Branco há mais de 5 anos
Entendida a matemática dos artigos, o próximo passo é modelar o deslizamento no computador e ver como ele se manifesta. Para isso, recomendo usar alguma linguagem de modelagem, como matlab ou octave. Eles tem, além do programa em si, uma linguagem própria para os códigos. Como o matlab é pago, recomendo usar o octave.
https://www.gnu.org/software/octave/
Sobre a sintaxe da linguagem, qualquer dúvida colocar aqui na tarefa ou me pedir um link pessoalmente (lembrar de atualizar a tarefa após qualquer progresso).
Sobre o que você tem que fazer em si:
Criar a velocidade pro robô [vx, vy, w*R] e a partir dela chegar nas velocidades das rodas (matriz de desacoplamento) [v1, v2, v3, v4]. Essas velocidades não tem deslizamento, já que foram geradas corretamente. Mas em alguma delas você adiciona um erro. Com isso, você tem agora, por exemplo: [v1*1.1, v2, v3, v4]. Que agora representa um deslizamento. Ai com a conta que ele dá, é pra gente conseguir ver se tem ou não deslizamento.
No final, é para termos um algoritmo não só que detecte deslizamentos bem, mas também corrija eles.
Atualizado por Vinicius Moraes há mais de 5 anos
Depois de pesquisar e ter uma melhor noção quanto ao octave eu consegui calcular a matriz que checa a relação de velocidades pra deslizamento. Só que eu cheguei num resultado diferente do que foi postado na tarefa, então travei ai. E não sei bem como implementar essa checagem no firmware, acredito que esse seja o proximo passo.
Atualizado por Onias Castelo Branco há mais de 5 anos
Vinicius Moraes escreveu:
Depois de pesquisar e ter uma melhor noção quanto ao octave eu consegui calcular a matriz que checa a relação de velocidades pra deslizamento. Só que eu cheguei num resultado diferente do que foi postado na tarefa, então travei ai. E não sei bem como implementar essa checagem no firmware, acredito que esse seja o proximo passo.
~~
D = [sin(pi/6) cos(pi/6) 1 %1
-sin(pi/6) cos(pi/6) 1 %2
sin(pi/4) -cos(pi/4) 1 %3
-sin(pi/4) -cos(pi/4) 1] %4
~~
~~~
B = pinv(D)
M = eye(4)-D*B
M= [3.333333333333333e-01 -3.333333333333331e-01 -2.357022603955158e-01 2.357022603955161e-01
-3.333333333333332e-01 3.333333333333335e-01 2.357022603955161e-01 -2.357022603955157e-01
-2.357022603955159e-01 2.357022603955159e-01 1.666666666666667e-01 -1.666666666666663e-01
2.357022603955161e-01 -2.357022603955160e-01 -1.666666666666663e-01 1.666666666666667e-01]
~~~
Uma coisa é a matriz D que voce usou está numa ordem diferente da nossa. (Não é errado, usar outra ordem nao é pra influenciar no problema). O equacionamento ta certo sim.
Sobre o próximo passo, envolve justamente usar essa matriz que você calculou pra determinar a condição de deslizamento. Se me lembro bem, é verificar esses dois sistemas aqui:
~~
-3.333333333333332e-01*v1 + 3.333333333333335e-01*v2 + 2.357022603955161e-01*v3 -2.357022603955157e-01*v4 = 0
-2.357022603955159e-01*v1 + 2.357022603955159e-01*v2 + 1.666666666666667e-01*v3 -1.666666666666663e-01*v4 = 0
~~
Para checar isso no firmware podemos fazer uma modificação no firmware que checa isso e sinaliza se há deslizamento. Temos que pensar num experimento para chegar na conclusão certa. Como que a gente pode saber com certeza se tem deslizamento ou se ele não percorre bem a rota por causa do deslizamento (tentar eliminar fatores externos).