Iniciei a semana 9 com a criação da ação, “GetPlatformOrientation”, para a orientação da plataforma consoante a orientação do aruco disposto na mesa. Posto isto, achou-se por bem, modificar o nó “integrated_referee” de modo a tornar o código mais organizado e compacto para posteriores utilizações. Assim, o nó “ integrated_referee” passou apenas a ler os comandos do gamepad Xbox e a “pedir” ações. Assim, a tarefa de aproximação da mesa com auxilio do laser, foi retirada deste mesmo nó, e foi criada uma ação, “GetPlatformAproximation”, para o efeito. Com estas alterações, surgiram alguns “bugs”, tais como a falha de cancelamento das ações quando o botão ‘dead man's switch’ era libertado. Este erro foi resolvido com a criação de threads de modo a que se consiga ler o gamepad e ao mesmo tempo executar o processo de “auto-picking”/”aproximação e orientação”.
Atualmente existem 2 nós árbitros, o integrated_referee (concebido por mim) e o r_hybrid (realizado pelo o Luís Sarmento) para comutação do modo automático / semiautomático na navegação da plataforma. O nó do Luís quando em execução, estava constantemente a enviar velocidades nulas para os motores, o que dificultava as ações implementas, uma vez que a plataforma se movia aos “soluços” . Deste modo, achou-se por bem criar um tópico,”/RobotStatus ” , publicado pelo nó “integratd_referee” no qual publica o modo/”status” que esta ativo {0,1,2,3,4}. Este tópico é então subscrito por o nó “r_hybrid” e este só publica velocidades quando está no modo de navegação, de modo a evitar conflitos.
No final desta semana, o laser de precisão do manipulador avariou o que foi necessário a sua troca e respetiva reconfiguração.
Na semana 10, para executar o processo de Bin-Picking , foi criado mais uma ação, “GetBinPicking”. Como o código de execução do Bin-Picking, realizado pela Joana Mota, estava em python, esta ação foi realizada na mesma linguagem, de modo a facilitar a sua integração. Na tentativa de integração do código, na sua totalidade, para uma ação, houve bastantes problemas, alguns dos quais “impossíveis” de superar. Na sequencia de código, eram lançados e terminados launch files sempre que se necessitava de algumas informações especificas, ou seja, os nós criados eram lançados apenas para executar uma determinada e única tarefa, encerrando-os quando executada. Uma vez que apenas se pode lançar launch files na main thread isto impossibilitou a sua implementação na ação, pois a execução da mesma é realizada numa thread diferente da principal. Visto que o método deixado pela Joana não era o mais robusto/aconselhado, alterei os seus nós que eram lançados temporariamente, para responderem a serviços. Assim, todos os nós são lançados ao mesmo tempo, e apenas realizam tarefas quando algum serviço é solicitado por parte do server da ação de BinPicking. De modo a que o código da joana continue igual, alterou-se os ficheiros “pointTFtransfer.cpp”, “SensorRS232.cpp” e “ObjDetection.cpp” e foram renomeados com os seguintes nomes respetivamente “ pointTFtransfer_v2”, “ SensorRS232_v2_service” e “ ObjDetection_v2”, para que os originais se mantenham .
Nesta semana, dediquei também algum tempo na arquitetura e escrita da dissertação.