Teste com 5 pontos na vinha

No quinto teste do primeiro cenário de testes a plataforma AGROB V16 move-se ao da vinha procurando que o seu manipulador atinja os 5 pontos de corte por ela distribuídos. Neste teste é efetuado o benchmarking dos algoritmos BiEST, LBKPIECE e LazyPRMstar para o primeiro mo- vimento e BiEST e KPIECE para o segundo movimento, todos configurados com o valor de 1mm no parâmetro longest_valid_segment_fraction. O objetivo final deste teste é chegar às melhores configurações a ser testadas com o modelo de vinha complexo.

Para os planeadores não limitados em tempo o valor máximo definido para o planeamento diminuiu para 10s, enquanto que o algoritmo LazyPRMstar, o único limitado temporalmente, dispõem apenas de 2 segundos. Os algoritmos escolhidos para os dois movimentos foram combi- nados gerando um total de 6 diferentes configurações. Os resultados podem ser consultados nas linhas 193 a 202 das tabelas, em baixo da célula TEST 5, preenchida a azul claro. De notar que,

contrariamente aos restantes testes que analisavam individualmente cada movimento, neste caso um teste completado com sucesso implica que sejam efetuados 5 movimentos da posição home do manipulador para diversos pontos de corte e outros 5 movimentos das posições de corte para a posição home.

A primeira impressão a retirar dos resultados é que há bastantes colisões com a vinha e ape- nas uma situação em que o planeamento de trajetórias não encontrou solução. Os resultados demonstram desta forma que nem todas as configurações apresentam resultados ótimos, como eventualmente seria de esperar, e que pontos em diferentes posições, com diferentes orientações e que possam estar distantes do manipulador, alteram a ideia inicial de quais seriam os melhores planeadores. Ainda que isto pudesse remeter para o teste de outros algoritmos neste ambiente, o peso que as questões temporais têm remete para que o mesmo não se suceda. Os resultados dos testes nas diferentes configurações apresentam-se natabela 5.16.

Tmax (s) Tmin (s) Tmed (s) TmedP (s) Nsucessos total BiEST + BiEST 32,716 20,723 26,416 5,283 5/10 BiEST + KPIECE 29,111 21,62 26,192 5,238 7/10 LBKPIECE + BiEST 45,471 32,623 38,275 7,655 5/10 LBKPIECE + KPIECE 43,399 38,197 39,366 7,873 5/10 LazyPRMstar + BiEST 33,008 18,42 23,474 4,694 10/10 LazyPRMstar + KPIECE 27,828 18,757 21,718 4,344 9/10

Tabela 5.16: Tabela com os melhores resultados do 5oteste do 1ocenário

De notar que o tempo médio por ponto é igual ao tempo médio total dividido por 5 e que o símbolo + separa o nome dos algoritmos usados nos primeiro e segundo movimentos, respetiva- mente.

A configuração que consiste no uso do algoritmo BiEST nos dois movimentos e a que usa o algoritmo LBKPIECE no primeiro obtiveram uma taxa de assertividade de 50%, a mais baixa de entre todos. Além disso, estes dois últimos casos obtiveram os piores resultados temporais, pelo que foram automaticamente excluídos do teste com a vinha complexa. A configuração que usou o algoritmo BiEST no primeiro movimento e KPIECE no segundo teve também uma taxa de assertividade de 70% pelo que também foi excluída.

Os melhores resultados obtidos, tanto em termos de assertividade como em termos temporais, foram registados pelas duas configurações que usam o algoritmo LazyPRMstar no primeiro movi- mento. No primeiro caso a assertividade foi perfeita, enquanto que no segundo apenas houve uma colisão no segundo movimento, pelo que o algoritmo LazyPRMstar, com o valor de 1cm no parâ- metro longest_valid_segment_fraction é claramente a melhor opção para o primeiro movimento. Em relação ao segundo movimento, o algoritmo BiEST foi superior ao KPIECE em termos de assertividade, ainda que seja ligeiramente mais lento. Por estas razões, estas duas configurações foram escolhidas para ser testadas no segundo movimento com a vinha complexa.

Além das considerações relativas aos algoritmos analisados, foi possível analisar o comporta- mento do MoveIt! nas situação em que o manipulador não se encontra próximo do ponto de corte (isto é, a escassos cm), dado que se tem que deslocar ao longo da vinha para aceder a outros.

Numa situação em que um ponto de corte se encontre à frente do manipulador e dentro do seu volume de atuação, seria de esperar que o MoveIt! conseguisse planear para ele, independente- mente da sua orientação, e desde que não houvesse objetos intransponíveis que impossibilitassem qualquer planeamento. Afigura 5.9demonstra uma situação deste tipo.

Figura 5.9: Situação onde o manipulador se encontra em frente ao ponto e não consegue computar nenhuma trajetória

Ainda que o esperado fosse o MoveIt! conseguir planear na situação da figura, o mesmo apenas foi conseguido quando o AGROB V16 já se encontrava a cerca de 20cm do ponto, no sentido positivo do eixo dos xx. A posição em que a plataforma se encontra quando o manipulador atinge o ponto é representada nafigura 5.10.

A particularidade deste ponto é o facto das lâminas da tesoura de poda se encontrarem a apontar para o chão. Ainda no ponto 5 deste mesmo teste ocorreu a mesma situação, sendo que neste caso o AGROB V16 se encontrava antes do ponto cerca de 30cm na direção do eixo dos xx.

Figura 5.10: Posição do AGROB V16 quando o MoveIt! conseguiu planear para o 2oponto no quinto teste do primeiro cenário

Afigura 5.11apresenta a posição da plataforma no momento em que o último ponto deste teste foi alcançado.

Figura 5.11: Posição do AGROB V16 quando o MoveIt! conseguiu planear para o 5oponto no quinto teste do primeiro cenário

Estes 2 resultados remetem para a premissa de que o MoveIt! não consegue planear para um ponto apenas porque este se encontra ao alcance do manipulador, mesmo que esta pareça perfeitamente viável. Outra particularidade destes casos é o facto de em todos os algoritmos se terem verificado comportamentos semelhantes, não havendo nenhum caso onde o MoveIt! tivesse conseguido calcular as trajetórias com o AGROB V16 em posições diferentes das verificadas nas imagens.

É de seguida apresentado o segundo cenário, o teste nele realizado e a sua análise de resultados.