Futebol de Robos F180 » Eletronica

Conseguimos atualizar boa parte dos pinos, exceto esses:
-PA9 USB_OTG_FS_VBUS
-PA10 USB_OTG_FS_ID
-PA11 USB_OTG_FS_DM
-PA12 USB_OTG_FS_DP
-PA13 SYS_JTMS.SWDIO
-PD10 CB
-PA4 D_CUR
-PC0 BAT_REF
-PE5 DAH
-PE2 ID_Button
-PD4 Reset(CS43L22)
-PD5 USB_overcurent
que estão declarados na imagem a seguir:

Muito bom galera, espero que vocês consigam finalizar até a competição!

Sobre os pinos, não sei se entendi muito bem o problema, mas provavelmente vocês não encontraram porque a maioria desses pinos (PA9, 10, 11, 12, 13, PD4 E PD5) são de funções que já vêm implementadas na biblioteca "Standard Peripherals" e não nas bibliotecas do robô em si. Se olharem no esquemático da placa mãe, vão ver que eles não são utilizados nela. Acho que o melhor seria checar se o cube já não tem algo pronto que implementa essas funções de USB, Reset e conexão JTAG/SWD, que com certeza tem.

Olhando o firmware que usamos na Robocup e o esquemático da placa mãe nova, com exceção dos pinos que mencionei acima, consegui encontrar o seguinte:

1. PA4 D_CUR:
   Saída do INA169 conectado no motor do drible, não sei se realmente há algo implementado a respeito desse pino pois antes era utilizado outro sensor de corrente com pinagem diferente. Tentem ver a implementação usada nos pinos de saída dos outros INAs.

1. PC0 BAT_REF:
   Pino ADC que mede a voltagem da bateria. No firmware antigo, as definições a respeito deste pino estão em "adc.h" e "adc.cpp" e ele é chamado na "Robo.cpp":
   

Em adc.cpp:
.PNG)
.PNG)

1. PE5 DAH:
   De acordo com o esquemático da placa mãe nova esse pino é referente ao controle do motor do drible, ou seja, necessita apenas de um PWM. No firmware da placa antiga esses comandos estão implementados no pino PB15 em "dibre.cpp" e "dibre.h":
   
   

1. PE2 ID_Button:
   Botão que controla o ID. Na placa mãe antiga, o controle do ID era feito de forma diferente, vejam como funciona o novo seletor de ID para fazer a implementação deste botão. No firmware da placa mãe antiga as definições deste pino estão em "Switch.h" e "bsp.cpp":
   
   .PNG)

1. PD10 CB:
   Comando de chute baixo. O pino está declarado em "Robo.cpp" e a implementação pode ser encontrada um pouco abaixo no mesmo código:
   
   

1. Sobre os pinos de chute (PB0, PD8 e PD10):
   Na placa de chute nova os pinos CT (que na placa nova vira Charge Enable, isso também deve ser modificado) e CA estão trocados em relação a placa antiga e é MUITO IMPORTANTE que isso seja levado em conta ao escrever o novo código. Na versão do código utilizada na Robocup (a branch é "placa-chute18") essa atualização já está feita, portanto, a configuração correta é a seguinte:
   PB0: Chute Alto (CA)
   PD8: Chute Baixo (CB, como já está)
   PD10: Charge Enable (CE, ou Charge_Enable, algo do tipo)

O pino de Charge Enable deve receber sinais na forma de degrau para que a placa funcione, para a competição implementamos da seguinte forma:
O pino era mantido em HIGH e a cada 6 segundos ou quando um chute era executado, o pino recebia um RESET e um SET. Isso vocês podem encontrar no código da branch que citei acima em "main.cpp" e "robo.cpp".

Espero ter ajudado e qualquer coisa podem perguntar.

Eai galera. Mais informação sobre esses pinos que eu coloquei no projeto do cube que não estão no firmware: Eles estão sendo usados sim, mas pela discovery. São pinos que já tem uma função pre-programada neles, que se a gnt alterar pode atrapalhar funções que a discovery já tem (como passar o código pro robo) ou o contrario (uns anos trás um dos pinos do encoder estava junto com um ci usado na discovery, ai ele não conseguia corrente suficiente pra funcionar.)

-PA9 USB_OTG_FS_VBUS
-PA10 USB_OTG_FS_ID
-PA11 USB_OTG_FS_DM
-PA12 USB_OTG_FS_DP

Eles são usados para comunicação com o cabo usb que a gnt coloca no computador, alterando esses pinos a gente não poderia usar o robo enquanto está conectado no pc (não daria pra fazer debug)

-PA13 SYS_JTMS.SWDIO

Esse pino é responsavel por passar o código pro microcontrolador.

-PD4 Reset(CS43L22)

o CS43L22 é um componente que converte sinal digital para sinal analogico, pra ser usado com o conector de fone de ouvido que vem na discovery. Esse pino está reservado porque o dando um sinal de Reset nesse CI ele não pode atrapalhar nenhuma funcionalidade do robo, pois esse CS43L22 usa muitos pinos que a gnt também usa

-PD5 USB_overcurent

É um medidor de corrente que chega do USB. Pra medidas de precaução, eu deixei ele quieto.

Abaixo tem um print do esquemático da discovery que pode ajudar no entendimento. Ele está no final do user manual dela (https://www.st.com/content/ccc/resource/technical/document/user_manual/70/fe/4a/3f/e7/e1/4f/7d/DM00039084.pdf/files/DM00039084.pdf/jcr:content/translations/en.DM00039084.pdf)

Ta complicado isso de CT ta trocado com CA da placa mãe nova em relação a antiga, a gente ta confuso em relação a isso e pensamos em deixar do modo como ta na branch NewBoard (roboime-firmware) considerando que onde tem CT no firmware na verdade é CA e vice versa. Os outros pinos estavam corretos depois que verificamos os locais que o joão falou e falta definir o botão pro id. Também estamos com um problema de que esta aparecendo no código na linha 191 como descrito na figura abaixo em que ele não identifica spi apesar de ta definido no código.

não estamos conseguindo resolver esse problema  que diz que não é possível abrir o arquivo stm32f4_flash.ld, o código é da branch NewBoard do github da roboime em roboime_firmware.

Hugo, o problema nesse caso é que o atollic não consegue achar o arquivo do linker script. Na imagem mesmo que vc colocou o endereço que ele está buscando é o do meu computador. C:\Users\Onias\... Ou seja, você tem que editar nas configurações do projeto onde ele procura pelo arquivo e colocar o endereço que está no seu computador. Em project -> properties. Ai no icone grifado voce seleciona o endereço desejado.


Sobre o linker em si, nele ficam as informações sobre o espaço na memória que sera destinado as partes do seu código. Por isso ele é importante. A ide pega o esta no linker na hr de passar pra placa e coloca as coisas que ela gerou nos espaços de memoria que estao escritos no linker.

O robô ja esta funcionando o drible e os outros motores de movimento alem do chute, mas um problema que estamos enfrentando agora é que ao fazer o elo-mec test o robô funciona normalmente após o inicio da comunicação (informada pela luz azul do led), mas o problema é no intervalo de tempo entre o robô ter sido ligado até antes do início da comunicação em que o drible é acionado sozinho. Um problema é que não foi definido na pinagem da placa mãe o DAL (drible Low), apenas foi definido o DAH (drible high). para tentar resolver o problema tentei primeiro manda sinal 0 no DAH no inicio da main: mas não deu certo continuo acionando sozinho o drible antes do início da comunicação. outra coisa que tentei foi colocar no while(1) da main, antes do interrupt  mas também não funcionou. Se alguem souber como resolver, acredito que após resolver esse problema a intel ja vai poder testar em campo com a placa mãe nova os robôs.

Link para o firmware mais atualizado https://github.com/Hugogomes9/firmwarenovo/tree/quase

Luiz Renault Leite Rodrigues escreveu:

Como é a tabela verdade de acionamento do drible? Quais sinais e quais funções?

Estou analisando aqui o modulo de motor.


O 4427 recebe x e manda x pro 7389. O MBL e o MBH do drible são VCC, MAL é GND e o MAH é o PWM.

Para o lado B, chega no 7389 vcc e vcc, logo, a saida MB é gnd.

Para o lado A, chega no 7389 gnd e PWM. Com isso abre o transistor de cima e a saída fica o PWM do MAH. Antes de receber o PWM o sinal está com um pull-down por conta do ir4427.

Com essa análise não consegui entender. Errei alguma coisa?

Segue a tabela verdade:
MAH (que é nomeado de DAH na verdade)=PWM
MAL=0
MBH=1
MBL=1

e o desenho da ponte H: 
S1 = MAH
S2 = MAL
S3 = MBH
S4 = MBL
concluimos apos uns testes que basta a discovery inicializar, que o robô começa a funcionar normalmente tanto movimento quanto drible e chute, mas no intervalo de tempo entre ligar o robô e a discovery inicializar o drible é acionado sozinho sem comando da intel, e é acionado na velocidade maxima.

IMPORTANTE:

Um problema que a intel estava tendo ao testar dois robôs em campo, era que a comunicação com 1 deles ficava ruim enquanto que com o outro robô ficava boa, esse problema ocorria ao tentar comunicar com os dois robôs ao mesmo tempo, inicialmente um robô nem se mexia enquanto que o outro se movia normalmente, pensamos primeiro que o problema era o nrf24l01, entretanto ao testar apenas o robô que não se movia junto com o outro, o robô funcionou normalmente tanto o elo-mec test quanto o zigue-zague.

Depois pensamos que o problema era com o código da intel, então em uma parte do código da intel em que havia um delay, foi reduzido esse tempo e depois disso ao testar os dois robôs juntos o que não se movia antes começou a se mover junto com outro entretanto ainda sim com problemas de comunicação pois o robô não seguia as ordens perfeitamente diferentemente do outro, tentamos reduzir ainda mais o delay porem começou a falhar mais ainda a comunicação. Após nada disso da certo recorremos ao Gustavo, e ele resolveu o problema.

O problema na verdade encontrava-se no firmware, especificamente nessa parte do codigo: no arquivo nrf24l01.cpp  o problema que havia aqui era que no parâmetro no_ack (no acknowledge) estava recebendo valor 0, ou seja estava ativado o ACK, que foi modificado nessa parte: , o ACK é um sinal que é enviado de transceptor para transceptor em uma comunicação, e o problema da comunicação com o robô era que o transmissor enviava um sinal ACK para o receptor (robô) e o transmissor( placa de comunicação da intel) ficava esperando receber o sinal ACK de volta para enviar uma ordem, o que causava problema de o robô não obedecer a intel no momento em que um comando era enviado.

Um outro erro que cometi no código foi na questão da troca de id do robô pelo botão do display, o problema é que da maneira como fiz inicialmente, ao clicar o botão do display, aparecia que tinha mudado o id e funcionava normalmente caso tivesse sido mudado primeiro no robô e depois no computador da inteligência, mas caso a inteligência muda-se primeiro, e logo após muda-se no robô a comunicação não iniciava, sendo necessário a inteligência mudar o id para outro qualquer e depois novamente colocar o id do robô (de alguma maneira isto reiniciava a comunicação) a maneira correta de chamar função que muda o id é como se segue abaixo na figura:  antes não havia nesses metodos a parte do nrf24 para reiniciar a comunicação após mudança de id