Para isto já há alguma coisa a dizer...

NOME: O nome de prova do robot foi Azeiteiro TT, nome que é parecido com Azeiteiro II, só falta a barra em cima :)
O TT para além de se parecer com II, pode ter outros significados como TodoTerreno, ou ... mais pelos gostos do Oliveira, Audi TT :)

MATERIAL: KIT normal(pic16f876+etc.. ) da organização do MR + Calculadora TI83
De salientar os novos sensores da sharp que compunham o kit deste ano.

DESCRIÇÃO: Todas as decisões de controlo foram tomadas pela calculadora TI83, ou seja, qualquer movimento efectuado pelo robot era por ordem da TI83.

Para isso usamos o kit PIC para fazer o interface entre o 'real' e o software.

No PIC foi programado em C o código de interface com a calculadora, leitura de sensores, filtragem de valores das leituras, andamento dos motores, etc.

Na calculadora existiam dois programas principais, o programa geral de "controlo de navegação" e um programa 'low level' de interface entre o PIC e o programa geral.
Comecemos pelo programa de interface. Este foi totalmente programado em z80 assembly e o seu objectivo era enviar e receber informação do PIC quando o programa geral (em basic nativo da máquina) pedia.

O programa geral, programado em Basic da TI como dito atrás, possuía o programa geral de navegação e tomada de decisões, ele enviava ao programa em assembly o valor da acção a realizar e carregava valores de variáveis com a informação (exemplo: velocidade dos motores, estado dos led's,etc).
 

Quando solicitado, o programa em assembly pedia valores ao PIC e depois guardava esses valores em variáveis normais da calculadora... para o programa geral continuar a sua execução.

NAVEGAÇÃO: O programa geral de controlo tinha alguns algoritmos interessantes que descobrimos nesta edição. Conseguimos fazer um contorno de paredes e sair dele, procurar o farol e tentar seguir na sua direcção. Apesar de não termos encoders (calcular distancias percorridas e posições) o código era capaz de 'adivinhar' a posição do farol em relação a sua posição actual.. e alguns testes que fizemos o resultado foi bom. Ainda mesmo sem encoders, colocamos a calculadora a desenhar no seu ecrã o caminho percorrido pelo robot (ou o que achava que percorria) e ainda tinha código (já não me recordo como fazia hehe) de retorno! Para quem viu o robot no teste das especificações técnicas, pode ver que o robot foi ao farol, virou.. e veio para trás para perto da sua partida. Foi aqui que o robot esteve no seu melhor...

O QUE CORREU MAL:

"A communications disruption can mean only one thing... invasion" - Sio Bibble - Starwars Eps1

O robot nas duas mangas andou um bocado no inicio... e acabou por parar a meio... problemas nas comunicações :/ O programa em assembly da calculadora usava uma rotina para enviar os bytes e receber "built-in" da ROM da calculadora. O problema desta rotina é que era muito 'high level', ou seja.. funcionava entre o sistema operativo da TI e o nosso programa em assembly, o que lhe permitia sempre que houvessem "communications disruptions"  o poder de cancelar a execução de todos os programas e mostrar um erro.

Porque houveram erros? Há sempre erros!! Nós com essa rotina não podíamos proceder a um tratamento de erros. Não perguntem porque é que não programamos a nossa própria rotina.. e inclui-mos código de correcção porque já não me lembro o porque! Havia conhecimentos para isso e penso que também houve tempo, terá sido esquecimento? Não me parece porque durante os testes acontecia encravar as vezes, talvez não com tanta frequência... penso que serviu de lição para a próxima...