Piloto Automático - Desafio
- As de espadas
- membro
- Mensagens: 166
- Registrado em: Ter Abr 03, 2007 1:48 pm
- Localização: Criciuma-sc
[quote:18cecb2009="alexcmag"]O PicoPilot atualmente também tem um "rudder home" pronto. É um produto recente, lembro que com certeza não existia quando comecei a pensar no assunto.[/quote:18cecb2009]
Voce se refere ao PICOPILOT-RTL ?
Alex, qual versão do picopilot que possue navegaçao através de uma rota + voar em uma altitude programada ?
Por acaso seria a versão NAT ou a 3500 ?
Voce se refere ao PICOPILOT-RTL ?
Alex, qual versão do picopilot que possue navegaçao através de uma rota + voar em uma altitude programada ?
Por acaso seria a versão NAT ou a 3500 ?
Let´s go Rock.
- alexcmag
- Equipe E-voo.com
- Mensagens: 14800
- Registrado em: Sex Fev 13, 2004 12:13 pm
- Localização: Sao Paulo SP
- Contato:
Isto, o Picopilot RTL volta para o ponto de partida. Mas repare que ele é bem simples, funciona como uma extensão de servo do leme.
Os demais vão ganhando funcionalidades.
O PP-N tem navegação seguindo waypoints programados, mas controla só leme.
O PP-SP é a mesma coisa, com auto-programação (aprende uma rota e repete).
O PP-NA tem navegação e mantém também a altitude.
O PP-NAT tem tubo de pitot e mantém também a velocidade no ar.
Os demais vão ganhando funcionalidades.
O PP-N tem navegação seguindo waypoints programados, mas controla só leme.
O PP-SP é a mesma coisa, com auto-programação (aprende uma rota e repete).
O PP-NA tem navegação e mantém também a altitude.
O PP-NAT tem tubo de pitot e mantém também a velocidade no ar.
- As de espadas
- membro
- Mensagens: 166
- Registrado em: Ter Abr 03, 2007 1:48 pm
- Localização: Criciuma-sc
- alexcmag
- Equipe E-voo.com
- Mensagens: 14800
- Registrado em: Sex Fev 13, 2004 12:13 pm
- Localização: Sao Paulo SP
- Contato:
Então, estou mesmo a fim de fazer algo do tipo faz tempo, estou animado com estas brincadeiras.
O RCAP do jeito que foi projetado qualquer um que tenha montado o Dakar OSD consegue montar.
Como sou meio chato, de cara eu mudaria algumas coisas:
1) Eliminar o regulador de tensão e eletrolíticos.
Os módulos GPS que o pessoal têm usado gastam muito pouco, em torno de 10mA, isto não pesa nada para o BEC do ESC.
2) Eliminar o MAX232.
Os módulos GPS que o pessoal têm usado têm saída LVTTL. Escolhendo uma entrada TTL do PIC para ligá-lo, dá para ler o sinal de 0V-3V diretamente. Mesmo que a entrada seja ST um transístor faz a função com muito menos área de placa e componentes.
3) Usar um dos conversores A/D internos do PIC e ligar os trim-pots diretamente entre o VCC e o GND com o cursor em uma das entradas analógicas do PIC.
4) Eliminar o resistor R1 e ajustar as flags do PIC para usar MCLR interno (já que não tem reset externo mesmo...)
5) Ligar a chave de reversão do servo do leme (S1) entre um pino do PIC e o terra, habilitando o pull-up interno e eliminando o resistor R4
6) Eliminar o cristal: dá para fazer comunicação serial sem ele numa boa (eu faço assim), o mesmo valendo para todas as entradas e saídas. Só o deixaria ali se precisar mesmo de toda a velocidade, mas um PIC16F88 por exemplo roda a 8Mhz com oscilador interno, o que já é bem rápido e provavelmente suficiente para processar o sinal do GPS com um programa um pouco mais enxuto.
7) Trocar o PIC por um de 18 pinos (repare que o de 28 pinos tem 11 pinos não utilizados, se eliminar o MCLR e o cristal, sobe para 14...
Ou então
Em vez de trocar o PIC por um de 18 pinos, trocar por um 18F e processar os waypoints dentro dele em vez de usar um sequenciador externo.
Na verdade até dá para sequenciar waypoints cmo o 16F88, por exemplo. Ele tem 256 bytes de EEPROM, o suficiente para guardar pelo menos uns 20 waypoints com um par de coordenadas de 32 bits cada e mais 4 bytes de controle e consegui um algoritmo que calcula ângulo para o destino com pequeno erro somente com operações inteiras (sem trigonometria)... Só não sei se tem RAM suficiente...
Mas primeiro preciso terminar o acelerador inteligente para moto e o OSD que estou fazendo, já faz uma semana que estou com o programa bem perto de fazer as funções básicas e isto está me incomodando, então devo demorar pelo menos algumas semanas antes de começar mais fundo no piloto automático.
O RCAP do jeito que foi projetado qualquer um que tenha montado o Dakar OSD consegue montar.
Como sou meio chato, de cara eu mudaria algumas coisas:
1) Eliminar o regulador de tensão e eletrolíticos.
Os módulos GPS que o pessoal têm usado gastam muito pouco, em torno de 10mA, isto não pesa nada para o BEC do ESC.
2) Eliminar o MAX232.
Os módulos GPS que o pessoal têm usado têm saída LVTTL. Escolhendo uma entrada TTL do PIC para ligá-lo, dá para ler o sinal de 0V-3V diretamente. Mesmo que a entrada seja ST um transístor faz a função com muito menos área de placa e componentes.
3) Usar um dos conversores A/D internos do PIC e ligar os trim-pots diretamente entre o VCC e o GND com o cursor em uma das entradas analógicas do PIC.
4) Eliminar o resistor R1 e ajustar as flags do PIC para usar MCLR interno (já que não tem reset externo mesmo...)
5) Ligar a chave de reversão do servo do leme (S1) entre um pino do PIC e o terra, habilitando o pull-up interno e eliminando o resistor R4
6) Eliminar o cristal: dá para fazer comunicação serial sem ele numa boa (eu faço assim), o mesmo valendo para todas as entradas e saídas. Só o deixaria ali se precisar mesmo de toda a velocidade, mas um PIC16F88 por exemplo roda a 8Mhz com oscilador interno, o que já é bem rápido e provavelmente suficiente para processar o sinal do GPS com um programa um pouco mais enxuto.
7) Trocar o PIC por um de 18 pinos (repare que o de 28 pinos tem 11 pinos não utilizados, se eliminar o MCLR e o cristal, sobe para 14...
Ou então
Em vez de trocar o PIC por um de 18 pinos, trocar por um 18F e processar os waypoints dentro dele em vez de usar um sequenciador externo.
Na verdade até dá para sequenciar waypoints cmo o 16F88, por exemplo. Ele tem 256 bytes de EEPROM, o suficiente para guardar pelo menos uns 20 waypoints com um par de coordenadas de 32 bits cada e mais 4 bytes de controle e consegui um algoritmo que calcula ângulo para o destino com pequeno erro somente com operações inteiras (sem trigonometria)... Só não sei se tem RAM suficiente...
Mas primeiro preciso terminar o acelerador inteligente para moto e o OSD que estou fazendo, já faz uma semana que estou com o programa bem perto de fazer as funções básicas e isto está me incomodando, então devo demorar pelo menos algumas semanas antes de começar mais fundo no piloto automático.
- Anexos
-
- rcap_simplificado.jpg (82.21 KiB) Exibido 19682 vezes
- alexcmag
- Equipe E-voo.com
- Mensagens: 14800
- Registrado em: Sex Fev 13, 2004 12:13 pm
- Localização: Sao Paulo SP
- Contato:
Vou ver se consigo tirar alguma imagem do OSD brazuca ainda hoje, ou amanhã no máximo.
Estou espremendo o código para conseguir mais resolução usando menos memória e menos velocidade.
Por enquanto troquei a tabela de caracteres para uma 8x8 que deve me dar mais resolução e usar menos processamento, apesar de ficar um pouco maior na ROM. Posso fazê-la ficar como 5x7 em outro formato se for preciso.
Vou usar o esquema de rotacionar o valor de uma porta para conseguir escrever 1 pixel por instrução, com alguns intervalos.
A 8Mhz (que dá para fazer com um PIC de 8 pinos sem cristal) dá para fazer 1 pixel a cada 0,5 microsegundo, portanto 110 pixels nos 55 microsegundos úteis de cada linha NTSC, o suficiente para desenhar 16 caracteres de 5x7 pixels com 2 pixels de espaço entre eles.
A 20Mhz (o mesmo PIC com cristal e sem overclock) dá para fazer 1 pixel a cada 0,2 microsegundo, portanto 275 pixels nos 55 microsegundos úteis da linha NTSC, o suficiente para 27 caracteres com 2 pixels de espaço entre eles, ou 23 caracteres com 4 pixels de espaço entre eles.
Com um PIC de 18 pinos e serial por hardware dá para receber dados sem nenhuma preocupação, portanto pelo menos um coprocessador para OSD rola, com o processamento dos dados de GPS em outro microcontrolador, mas de vou tentar fazer tudo caber em um só.
Estou espremendo o código para conseguir mais resolução usando menos memória e menos velocidade.
Por enquanto troquei a tabela de caracteres para uma 8x8 que deve me dar mais resolução e usar menos processamento, apesar de ficar um pouco maior na ROM. Posso fazê-la ficar como 5x7 em outro formato se for preciso.
Vou usar o esquema de rotacionar o valor de uma porta para conseguir escrever 1 pixel por instrução, com alguns intervalos.
A 8Mhz (que dá para fazer com um PIC de 8 pinos sem cristal) dá para fazer 1 pixel a cada 0,5 microsegundo, portanto 110 pixels nos 55 microsegundos úteis de cada linha NTSC, o suficiente para desenhar 16 caracteres de 5x7 pixels com 2 pixels de espaço entre eles.
A 20Mhz (o mesmo PIC com cristal e sem overclock) dá para fazer 1 pixel a cada 0,2 microsegundo, portanto 275 pixels nos 55 microsegundos úteis da linha NTSC, o suficiente para 27 caracteres com 2 pixels de espaço entre eles, ou 23 caracteres com 4 pixels de espaço entre eles.
Com um PIC de 18 pinos e serial por hardware dá para receber dados sem nenhuma preocupação, portanto pelo menos um coprocessador para OSD rola, com o processamento dos dados de GPS em outro microcontrolador, mas de vou tentar fazer tudo caber em um só.
- As de espadas
- membro
- Mensagens: 166
- Registrado em: Ter Abr 03, 2007 1:48 pm
- Localização: Criciuma-sc
Grannnnde Alex, como é bom saber que estais interessado, fico muito feliz :D :D
Algumas mudanças.... modesto !
Bem como o projeto do RCAP deve estar completando uns dois anos, mudanças são sempre bem vindas.
Como ele foi programado para ler dados dos receptores gps através da porta serial, e hoje temos receptores OEM com saída TLL, o MAX232 está descartado.
"Em vez de trocar o PIC por um de 18 pinos, trocar por um 18F e processar os waypoints dentro dele em vez de usar um sequenciador externo."
Como faria pra gravar os waypoints ? (adorei não preci$ar de um WPS)
Teria como aumentar a capacidade de armazenamento para uns 40 pontos, substituindo o 16F88 por outro que tenha uma memoria de 512 ?
Seria possivel com o PIC 18F452 ?
Não entendo nada de eletrônica, desculpe qualquer coisa q tenha me equivocado. :)
Algumas mudanças.... modesto !
Bem como o projeto do RCAP deve estar completando uns dois anos, mudanças são sempre bem vindas.
Como ele foi programado para ler dados dos receptores gps através da porta serial, e hoje temos receptores OEM com saída TLL, o MAX232 está descartado.
"Em vez de trocar o PIC por um de 18 pinos, trocar por um 18F e processar os waypoints dentro dele em vez de usar um sequenciador externo."
Como faria pra gravar os waypoints ? (adorei não preci$ar de um WPS)
Teria como aumentar a capacidade de armazenamento para uns 40 pontos, substituindo o 16F88 por outro que tenha uma memoria de 512 ?
Seria possivel com o PIC 18F452 ?
Não entendo nada de eletrônica, desculpe qualquer coisa q tenha me equivocado. :)
- alexcmag
- Equipe E-voo.com
- Mensagens: 14800
- Registrado em: Sex Fev 13, 2004 12:13 pm
- Localização: Sao Paulo SP
- Contato:
Mesmo para enviar e receber serial RS232 não é preciso usar exatamente o MAX232, principalmente a distâncias curtas, como neste caso, onde não é preciso obedecer a norma completa para que a coisa funcione de forma segura e eficiente.
A melhor prova disto são as centenas de milhões de mouses seriais que já foram fabricados, que além de não usar MAX232 para enviar dado ainda são alimentados pela serial do PC...
Em qualquer PIC18F dá para gravar waypoints em grande número, já que têm bastante RAM e Flash.
Num 18F2550 (2K SRAM, 32K flash), por exemplo, dá tranquilamente para buferizar os waypoints na RAM enquanto conectado no PC, depois gravar na Flash.
Para gravar os waypoints pode-se usar uma interface serial (no caso dos 16Fxxx) ou USB (no caso dos 18Fxxx, mas ainda estou aprendendo a lidar com USB nele).
Ou algum dispositivo removível (cartão SD, pen-drive, smartcard, SIMcard, etc.).
Ou, melhor ainda... conectar um transceiver de 2.4Ghz ou 900Ghz, que já serviria para:
- Programação pelo PC;
- Controle, no lugar do receptor normal;
- Telemetria.
A melhor prova disto são as centenas de milhões de mouses seriais que já foram fabricados, que além de não usar MAX232 para enviar dado ainda são alimentados pela serial do PC...
Em qualquer PIC18F dá para gravar waypoints em grande número, já que têm bastante RAM e Flash.
Num 18F2550 (2K SRAM, 32K flash), por exemplo, dá tranquilamente para buferizar os waypoints na RAM enquanto conectado no PC, depois gravar na Flash.
Para gravar os waypoints pode-se usar uma interface serial (no caso dos 16Fxxx) ou USB (no caso dos 18Fxxx, mas ainda estou aprendendo a lidar com USB nele).
Ou algum dispositivo removível (cartão SD, pen-drive, smartcard, SIMcard, etc.).
Ou, melhor ainda... conectar um transceiver de 2.4Ghz ou 900Ghz, que já serviria para:
- Programação pelo PC;
- Controle, no lugar do receptor normal;
- Telemetria.
- As de espadas
- membro
- Mensagens: 166
- Registrado em: Ter Abr 03, 2007 1:48 pm
- Localização: Criciuma-sc