feat: initial commit - Carinha Control Panel v1.0 com UI glassmorphism, watch-bar, emojis, braco robotico e conversa IA
This commit is contained in:
julio
@@ -0,0 +1,16 @@
|
||||
# Análise do pacote original — 2026-10-05
|
||||
|
||||
Arquivo fornecido: brazo-robotico-arduino-5-0-archivos-step-guardar-re20260417-1-scro13.zip. Contém peças STEP, código Arduino em RAR e aplicativo de controle em RAR. Arquivos extraídos para análise; nenhum aplicativo executado e nenhum comando de movimento enviado.
|
||||
|
||||
Código analisado: BrazoRobotico5.0_arduino_code.ino.
|
||||
|
||||
- PCA9685 pela biblioteca Adafruit_PWMServoDriver, 50 Hz.
|
||||
- Faixa definida no código: 500–2500 µs, mapeada de 0–180 graus. Essa é uma configuração do projeto, não garantia de faixa segura para qualquer MG996R ou montagem.
|
||||
- Sete controles lógicos e oito saídas físicas.
|
||||
- Canais: 0 garra, 1 punho 1, 2 punho 2, 3 braço superior, 4 braço inferior, 5 antebraço, 7 base.
|
||||
- Canal 6 acompanha o antebraço (canal 5) no sentido contrário: ângulo 180 menos o ângulo do canal 5. Pares devem ser calibrados antes de acoplar; os testes individuais atuais não fazem essa sincronização.
|
||||
- Código inicia todos os motores em 90 graus. Não reproduzir esse movimento automático na instalação atual.
|
||||
- Aplicativo original comunica com o Arduino pela serial a 9600 baud. MODE seleciona manual/automático, SPD ajusta velocidade, comandos de posição usam índice lógico 1–7 e ângulo, separados por espaço e terminados por newline.
|
||||
- Pacote inclui aplicativo Linux Raspberry Pi 32 e 64 bits. A presença desse aplicativo não implica controle direto do I²C do Orange Pi: o caminho original passa pelo Arduino.
|
||||
|
||||
Diferença com o painel atual: faixa absoluta aceita 1000–2000 µs, cartões iniciais 1400–1600 µs, seis canais independentes e sinal com expiração. Para ampliar, implementar calibração por servo; manter limites salvos estreitos até medição do fim de curso. Adaptar protocolo e articulações em etapa posterior, quando montagem e servos forem confirmados.
|
||||
@@ -0,0 +1,31 @@
|
||||
# Aba Braço robótico
|
||||
|
||||
## Calibração manual em passos de 100 µs
|
||||
|
||||
Dentro de Calibrar limites por canal: selecionar canal, habilitar testes, usar −100 / +100 µs ou Testar posição. Sinal expira em 2 s. Faixa absoluta 500–2500 µs, sem varredura automática nem detecção de batente. Marcar mínimo, centro ou máximo desliga os sinais e atualiza apenas a seleção local; Salvar calibração grava no Orange Pi, validando mínimo < centro < máximo e todas as posturas existentes. Se uma postura ficar fora da faixa nova, ajustar ou excluir a postura antes de salvar.
|
||||
|
||||
Canais 5/6 são testados em par, com deslocamentos opostos em relação aos centros salvos. Marcar um extremo de um canal também marca o extremo oposto do outro. Centro pode ser salvo individualmente; ambos precisam representar a montagem neutra correspondente. Mapeamento de graus agora é linear por trecho, 0°=500, 90°=centro calibrado, 180°=2500 µs, sempre restringido pelos extremos salvos. Graus são nominais, não medidos. Nenhum motor acionado durante validação automatizada.
|
||||
|
||||
Cinco sequências prontas: Acenar, Olhar para os lados, Alcançar e recolher, Garra e punho, Apresentação. São geradas dentro dos limites calibrados, sem sobrescrever posturas existentes. Prévia anima uma representação esquemática sem enviar movimento; solicita desligamento prévio dos sinais. Executar exige movimento ativado e envia sete ângulos/eight saídas com o antebraço espelhado. A interpolação usa uma fração comum para todas as articulações chegarem juntas ao fim de cada trecho; a sincronização é dos comandos, sem feedback mecânico. Animação mostra comandos nominais, não cinemática validada do modelo STEP. Testes de prévia verificam ausência de chamadas mover.
|
||||
|
||||
Bateria do celular adicionada ao painel principal: percentual e indicador carregando. Novo APK gerado e instalado por ADB no S10; precisa reabrir Carinha após instalação. O Android lê ACTION_BATTERY_CHANGED e inclui dados na telemetria. Sem conexão ou sem dado, o painel informa aguardando. Nenhum percentual é inferido do PC ou da placa.
|
||||
|
||||
Refinamento visual: sliders pretos largos com marcadores brancos, valores maiores, botões arredondados, fundo branco e ilustração SVG própria com volumes, juntas e conexões. Layout verificado em desktop e celular; testes simulados dos controles permanecem passando. Nenhuma alteração de pulsos, calibração ou canais nesta revisão visual.
|
||||
|
||||
Criada em 2026-10-05: http://192.168.1.35:8100/braco. Interface web inspirada na captura do aplicativo FABRI_CREATOR fornecida pelo usuário, com ilustração esquemática própria. Não é o executável Java incorporado nem uma cópia exata da arte original.
|
||||
|
||||
Sete controles: garra 0, punho 1 no canal 1, punho 2 no canal 2, braço superior 3, braço inferior 4, antebraço 5 com canal 6 espelhado, base 7. Cada postura enviada controla os oito canais. Confirmar ligações e montagem antes de ativar. Não misturar comandos das abas Servos e Braço ao mesmo tempo.
|
||||
|
||||
Movimento desativado ao abrir. Ativar movimento não envia pulsos por si só. Arrastar, carregar postura com movimento ativado ou Reproduzir envia a postura completa. O indicador de graus é nominal, conforme a fórmula do Arduino: 500 + ângulo * 2000 / 180 µs. Não mede o eixo físico. Velocidade de 5–90 graus/s é interpolação dos comandos no navegador; não há garantia da velocidade mecânica. A posição inicial estimada é a seleção da tela, não leitura do motor.
|
||||
|
||||
Calibração inicial independente da aba de testes: 1400–1600 µs nos oito canais (aproximadamente 81–99 graus nominais). Expandir gradualmente com os motores sem carga conforme montagem. API aceita 500–2500 µs; essa faixa do código original não é garantia de curso seguro do MG996R. O centro 1500 precisa estar dentro da calibração. Antebraço combina os limites dos canais 5 e 6 para ambos ficarem dentro da faixa.
|
||||
|
||||
Salvar postura grava a seleção sem movimentar e desativa o movimento. Centro na tela para os sinais e apenas seleciona 90 graus. Reproduzir executa todas as posturas uma vez, com intervalo de 700 ms entre elas. Parar sinais cancela reprodução e desliga o PWM; não corta a alimentação elétrica. Ao ocultar a aba, o cliente solicita parada. O watchdog do servidor também desliga cada canal cerca de 2 segundos após o último comando: um braço suspenso pode perder sustentação. Nesta etapa testar com braço apoiado. Não há manutenção indefinida de torque.
|
||||
|
||||
Configurações e até 100 posturas ficam em /opt/carinha-pc/braco.json. Não sobrescreve servos.json, app-config.json ou aparencia.json. Exportar gera JSON carinha-braco-v1. Importar aceita esse formato e valida todas as posições antes de salvar, sem mover. Não importa diretamente arquivos de postura do aplicativo original: formato ainda não analisado.
|
||||
|
||||
Backend compartilhado com o driver e watchdog de servos, validando a postura inteira antes de escrever I²C. Escrita de oito canais é sequencial sob lock, não eletricamente simultânea. Erro I²C solicita parada. Em falha de rede, não há novos comandos; watchdog limita duração do sinal. Movimentos são solicitados pelo navegador, não executados autonomamente na placa.
|
||||
|
||||
Verificado: quatro testes do braço (par espelhado, limites antes da escrita, persistência e abertura sem movimento), oito do driver, 12 do servidor; navegador com API simulada para controles, velocidade, parada, salvar/reproduzir, layout mobile; regressões das abas de servos. Nenhum motor acionado nos testes da implantação. Verificação física e calibração pendentes.
|
||||
|
||||
Retorno: backup anterior em /opt/carinha-pc/backup-braco-20261005. Parar carinha-pc, restaurar kiosk-server.py, painel.html e servos.html desse backup e reiniciar. Preservar braco.json. Arquivos da nova funcionalidade: braco.py, braco.html, braco.js. Serviço continua carinha-pc na porta 8100.
|
||||
@@ -0,0 +1,39 @@
|
||||
# Conversa e memória local — 2026-10-05
|
||||
|
||||
## Correção de repetição — 2026-10-05
|
||||
|
||||
### Segunda ocorrência: troca de assunto
|
||||
|
||||
A sequência céu azul → “está bravo?” continuou repetindo mesmo após a primeira correção. O contexto atual foi reduzido à pergunta atual e às lembranças explícitas (até 550 caracteres); as respostas anteriores permanecem no histórico exibido, mas não são reenviadas ao modelo. Isso limita referências como “explique sua resposta anterior”, portanto não equivale a uma conversa com contexto completo.
|
||||
|
||||
Teste real da sequência no servidor após a mudança: céu → resposta sobre atmosfera (2,81 s); “está bravo?” → “Bravo! Como você está?” (1,14 s); música → “Sim, posso ouvir música para você” (1,61 s). A repetição exata desapareceu nesta sequência, mas o modelo ainda interpretou bravo como elogio e inventou uma capacidade de música. Não considerar esses testes como prova de inteligência conversacional adequada. Seis testes unitários passaram, incluindo a ausência de respostas anteriores no payload. Para melhorar a compreensão, é necessário avaliar outro modelo com perguntas de aceitação, não continuar somente ajustando saudações.
|
||||
|
||||
O modelo acertou uma pergunta aritmética sem histórico, mas repetia saudações quando recebia as respostas defeituosas anteriores. A migração acrescenta mensagens.versao: entradas antigas permanecem visíveis, mas não entram no contexto; novas entradas usam versão 1. Backup no Orange Pi em backup-conversa-20261005/memoria-antes-correcao.db. Lembranças preservadas. Contexto mais direto, temperatura 0,2 e proteção contra chamar o usuário pelo nome do personagem. Perguntas diretas de horário usam relógio do servidor em UTC−3 (São Paulo), sem inferência.
|
||||
|
||||
Verificação real após correção: saudação “Bom dia!”, conta “2 + 3 = 5”, nome “Carinha”, horário do servidor e resposta relacionada à pergunta sobre o céu. O modelo ainda deu uma explicação incompleta sobre o céu: esta correção remove a repetição observada, não aumenta a capacidade do Qwen0.6B. Tempos das respostas geradas 3,7–7,8 s; horário imediato no backend. Cinco testes de conversa, um do cérebro e 12 HTTP passaram. Não foi necessário trocar APK ou modelo.
|
||||
|
||||
Design aprovado: texto pelo painel, respostas curtas animadas no celular e memória no Orange Pi. Implementação no fluxo existente; sem reconhecimento novo de gestos ou controle de motores.
|
||||
|
||||
## Uso
|
||||
Abra /painel, escreva em Conversar com o Carinha e clique Enviar. A resposta aparece no histórico e no celular com escrita animada, acompanhada de uma expressão existente. O app deve estar conectado; respostas com mais de 60 segundos não são reapresentadas ao reconectar.
|
||||
|
||||
Em Lembranças do Carinha, salve fatos e preferências explicitamente. Há até 30 lembranças de 300 caracteres. Cada uma pode ser apagada; apagar tudo também remove o histórico. O histórico persistente conserva até 100 mensagens; as últimas 12 são enviadas ao modelo. O modelo continua Qwen3-0.6B Q4_K_M no celular; memória não é treinamento de pesos.
|
||||
|
||||
## Estrutura e verificação
|
||||
conversa.py usa SQLite memoria.db no Orange Pi. Respostas JSON restritas a texto de até 280 caracteres e uma expressão permitida. Texto renderizado por textContent. Uma inferência por vez, compartilhada com a personalidade automática; erros aparecem no painel. Não há envio de comando a motores. Limpeza invalida resposta em andamento.
|
||||
|
||||
Plano executado: testes de persistência/remoção/validação; módulo de conversa; rotas e integração de exclusão mútua; painel e balão; deploy preservando configurações; teste real de inferência e navegador.
|
||||
|
||||
Limitações: modelo pequeno pode errar fatos ou não respeitar perfeitamente preferências; não há fala, auto treinamento, identificação de joinha nem confirmação física de exibição. O endpoint de status não confirma leitura pelo aparelho.
|
||||
|
||||
Validação: 3 testes de memória/validação e 12 testes HTTP existentes passaram. Navegador verificou envio, memória e balão com respostas simuladas; teste real no S10 gerou resposta em 4,11 s. Contexto limitado para caber no executor de 1024 tokens: lembranças relevantes até 550 caracteres e turnos recentes até 750 caracteres. Não há garantia de lembrar todos os fatos simultaneamente.
|
||||
|
||||
Teste real de recuperação: após ajustar o prompt, uma lembrança temporária com o nome Jullio foi recuperada em 9,49 s. O modelo ainda confundiu o pronome (respondeu na primeira pessoa); a memória é contexto, não garantia de resposta correta. A lembrança temporária foi apagada; mensagens de teste permanecem no histórico. Reabra o app para carregar o HTML atualizado; não requer APK novo enquanto conectado ao servidor.
|
||||
|
||||
## Aba Conversar — 2026-10-05
|
||||
|
||||
Conversa movida para /conversa, acessível pela navegação em todas as abas. O painel principal mantém câmera e configuração. Rotas da API, histórico, provedor e lembranças permanecem os mesmos.
|
||||
|
||||
## Recarregar tela pelo painel
|
||||
|
||||
Botao Recarregar tela do celular envia comando pela fila, exclusivo para carinha.html?aparelho=1. O HTML usa location.replace com parametro de atualizacao; nao fecha a atividade nem reinstala APK. Servidor recusa quando telemetria esta offline. Solicitar nao confirma que a tela foi atualizada. A primeira adocao exige reabrir o app uma vez para receber o handler; depois o botao funciona enquanto app aberto e conectado. Teste de navegador confirmou recarregamento sem ciclo infinito.
|
||||
@@ -0,0 +1,32 @@
|
||||
# Dashboard Carinha — 05/10/2026
|
||||
|
||||
Objetivo: unificar todas as páginas de operação em tema escuro/ciano com navegação lateral. A tela do celular continua em tela cheia.
|
||||
|
||||
## Revisão
|
||||
- Navegação repetida em cinco páginas, com nomes e estilos diferentes.
|
||||
- Conversar copiava grande parte do CSS de câmera, incluindo regras sem elementos correspondentes.
|
||||
- Braço possuía duas camadas de CSS e tema claro divergente.
|
||||
- Treinamento misturava rotina, geração e biblioteca de reações.
|
||||
- Chave/modelo Gemini só eram configuráveis fora da interface.
|
||||
- Biblioteca permitia prévia e feedback, mas não edição, duplicação, desativação ou desfazer.
|
||||
|
||||
## Organização
|
||||
Visão geral, Câmera e rosto, Conversar, Emojis, Treinamento, Servos, Braço, API. Shell, tipografia, campos, botões, navegação e estados compartilhados. Regras específicas de câmera e braço ficam separadas.
|
||||
|
||||
Emojis: biblioteca com busca, prévia, mostrar/parar no celular, edição de metadados e emoji pronto, criação manual, duplicar, ativar/desativar e excluir com desfazer persistente. SVG gerado é preservado; mudar para emoji é uma ação explícita. Desativar impede a escolha automática pela conversa.
|
||||
|
||||
API: visualizar estado sem revelar a chave, trocar chave/modelo Gemini, testar conexão. Chaves ficam em arquivo privado no servidor, nunca nas respostas HTTP ou Git. Não adicionar provedores que não possuem integração.
|
||||
|
||||
Calibrações, bancos e serviço existentes preservados. Nenhum movimento de motor é disparado ao abrir telas. Validação: testes de API/reversibilidade e navegação responsiva de todas as telas, sem erros JS; fluxos atuais de conversa, câmera e servos mantidos.
|
||||
|
||||
## Entrega e verificações
|
||||
|
||||
Oito páginas usam o mesmo menu lateral e o mesmo tema. Removidos os blocos de CSS genérico repetidos, a navegação inline e o CSS de câmera que havia sido copiado para Conversar. A biblioteca foi separada de Treinamento. Exemplares de SVG continuam intactos. O feedback também participa do desfazer.
|
||||
|
||||
45 testes Python passaram, incluindo migração de banco antigo, recuperação de SVG e histórico persistente, confidencialidade da chave, API, conversa, treinamento e controles dos servos. Testes de navegador verificaram oito páginas com menu ativo, largura de 390 px sem rolagem horizontal e ausência de erros JavaScript. Criar, prévia de emoji dentro dos olhos sem íris branca, excluir, desfazer e parar passaram em servidor de teste separado. No Orange Pi, as oito rotas publicadas foram verificadas, acesso ao arquivo privado retornou 404 e o teste real do Gemini respondeu em 0,77 s. Não foi realizado teste físico de motores.
|
||||
|
||||
Backup prévio de HTML/JS/Python e banco de treinamento: /opt/carinha-pc/backup-dashboard-20261005. Configurações dos servos e do braço não foram alteradas. Para voltar ao código anterior de treinamento, também é necessário restaurar o banco anterior, pois a migração acrescenta colunas; restauração do backup do banco perde as alterações feitas após esse backup.
|
||||
|
||||
Duplicações intencionais: carinha.html também é embutido no APK para fallback sem servidor; tabelas de gestos no renderer/servidor representam o protocolo existente. Não foram removidas durante o redesenho.
|
||||
|
||||
A tela API cobre o provedor integrado Gemini e aponta para a opção local Qwen. DeepSeek não foi integrado nesta reformulação. O painel continua destinado à rede local, sem login de usuários.
|
||||
@@ -0,0 +1,25 @@
|
||||
# Controle da Carinha pelo PC
|
||||
|
||||
Desenho aprovado no chat em 04/10/2026. O servidor roda no Windows, independente da placa. O Galaxy S10 continua mostrando o rosto em primeiro plano.
|
||||
|
||||
## Fluxo
|
||||
|
||||
`servir-local.bat` inicia o servidor na porta 8100. O painel `/painel` permite conectar o celular por ADB, configurar rosto/cor/gestos, volume, gestos automáticos, reação ao som e movimento, sensibilidade e tempo para dormir. Os ajustes persistem em JSON no PC e são aplicados pela página sem recarregar.
|
||||
|
||||
O app usa uma única sessão Camera2 frontal para análise e prévia. Quadros YUV são convertidos em JPEG colorido com orientação da câmera e enviados no máximo cinco vezes por segundo, em thread de rede separada. Não abre a página de diagnóstico no celular. O painel mostra a imagem somente quando a transmissão está habilitada; ao desativar ou perder conexão, esconde a imagem antiga. Nenhuma gravação de vídeo ou áudio. O microfone envia somente o nível.
|
||||
|
||||
## Interfaces
|
||||
|
||||
- `/app/config`: GET lê; POST valida e salva ajustes. Campos: `preview`, `auto`, `audio`, `volume`, `ouvir`, `reagir`, `somlim`, `somganho`, `somaltolim`, `sompausa`, `somcooldown`, `movlim`, `movforte`, `movcooldown`, `movolhar`.
|
||||
- `/app/status`: POST recebe estado do rosto, microfone e movimento; GET informa telemetria e conectividade com prazo de cinco segundos.
|
||||
- `/camera/frame`: POST recebe JPEG de até 1 MB; GET devolve último quadro somente se transmissão habilitada e quadro recente (até três segundos).
|
||||
- `/app/connect`: POST disponível apenas pelo localhost, com IP IPv4 e porta ADB validados; usa argumentos fixos para conectar e abrir o app apontando ao PC.
|
||||
- Rotas existentes `/config`, `/faces`, `/gestos`, `/fila` mantidas. O painel não consome `/fila`.
|
||||
|
||||
## Falhas e validação
|
||||
|
||||
## Economia de tela adicionada pelo usuário
|
||||
|
||||
Configuração `economia` (padrão true), `brilho` (0.70), `brilhoRepouso` (0.08) e `repousoTela` (30 segundos). O Android aplica brilho à janela do app, restaurando o padrão do sistema ao sair. Inatividade/dormir reduz brilho; som, movimento e comandos restauram. Gestos espontâneos não contam como atividade do usuário. Teste JVM cobre a decisão; teste físico está pendente, conforme REGISTRO.md.
|
||||
|
||||
Rede indisponível não bloqueia câmera nem animação; mantém no máximo um quadro pendente. Captura e envio param quando app vai para segundo plano. Painel distingue configuração salva de estado confirmado pelo celular. Testes HTTP reais cobrem persistência, validação, expiração de quadros e isolamento da fila. Teste JVM cobre layout YUV com row/pixel stride. Compilar e verificar assinatura do APK, instalar no S10 conectado e conferir imagem e telemetria pelo servidor.
|
||||
@@ -0,0 +1,19 @@
|
||||
# Figurinhas SVG dinâmicas — 2026-10-05
|
||||
|
||||
Gemini recebe a descrição do app, fundo preto, olhos, modos olhos/ao_redor e limites do desenhador. Ele cria desenhos novos como caminhos vetoriais preenchidos em JSON. Não recebemos nem executamos markup SVG arbitrário: apenas M/L/C/Q/Z, cores hex e coordenadas limitadas. Até 16 formas e 600 caracteres por caminho; renderer monta elementos SVG por APIs de DOM.
|
||||
|
||||
Na aba Treinamento, Desenhar e mostrar cria, valida, salva e publica a figurinha diretamente para o app conectado. Não depende de aprovação ou de clicar Mostrar no celular depois. A prévia permanece disponível. Nos olhos, os dois desenhos acompanham a geometria do rosto e o brilho branco fica oculto. Ao redor, a figurinha pulsa e gira suavemente. Duração visual de seis segundos. Ainda não há animação independente das partes de cada desenho.
|
||||
|
||||
Na conversa Gemini: ele recebe catálogo de reações e escolhe uma adequada. Se escolhe 0 (nenhuma apropriada), a resposta de texto aparece primeiro e o servidor pede uma figurinha nova em segundo plano, publicando ao concluir. Uma criação de cada vez; se já houver geração em andamento, não inicia outra. Não é instantâneo: depende de uma chamada extra e da cota Google. Erros aparecem em Treinamento. Não há alteração dos pesos do modelo.
|
||||
|
||||
Verificação: gerados pelo Gemini uma xícara com vapor/coração nos olhos, um presente aberto com estrelas e um coração com asas. Navegador confirmou SVGs gerados renderizados ao redor e nos dois olhos, brilho oculto e ausência de erros JS. Isso não confirma visualização física no celular. Validação rejeita script, URLs e coordenadas fora do limite. Receitas antigas continuam compatíveis.
|
||||
|
||||
## Consulta de melhoria do rosto
|
||||
|
||||
Contexto técnico e preferências foram enviados ao Gemini; não foi enviada imagem nesta consulta. Resultado em SUGESTOES-GEMINI.json. Ele sugeriu glow, micromovimentos, transições de formas, sincronização emocional e vinheta. Avaliação local: já existem micromovimentos; priorizar refinar, não duplicar. Manter preto no AMOLED e usar brilho localizado. Mudanças estéticas sugeridas ainda não aplicadas.
|
||||
|
||||
Atualize Treinamento e use Recarregar tela do celular no painel após a primeira adoção desse comando. Nenhum APK novo necessário no modo conectado.
|
||||
|
||||
## Prompt visível e objetos reconhecíveis
|
||||
A aba Treinamento exibe a orientação atual e o último prompt integral enviado para criar figurinhas, incluindo pedidos da conversa. O último prompt é persistido antes da chamada, inclusive se a API falhar. A orientação pede objetos reais em SVG, proíbe substituir por emoticons, e especifica halteres dentro dos olhos com pesos espessos, tamanho e contraste com o fundo dos olhos. A animação continua sendo da figurinha inteira. A biblioteca antiga permanece disponível; reações existentes não são redesenhadas automaticamente. Verificados os testes de validação e treinamento, e a exibição do prompt e SVG na prévia Chromium.
|
||||
|
||||
@@ -0,0 +1,21 @@
|
||||
# Gemini no Carinha — 2026-10-05
|
||||
|
||||
Conversa pelo Gemini configurada no Orange Pi. Modelo atual: gemini-flash-lite-latest. O alias solicitado gemini-flash-latest e os modelos Flash 3.7/3.8 retornaram HTTP 503 com mensagem de alta demanda. Flash Lite respondeu nos testes, por isso é a opção ativa.
|
||||
|
||||
## Uso
|
||||
|
||||
Atualize /painel. Em Conversar com o Carinha, escolha Gemini ou Qwen local. Não é necessário atualizar o APK: o celular continua recebendo texto e expressão do Orange Pi. Gemini precisa de internet. A chave fica em /etc/carinha-gemini.env, permissão 600, carregada por EnvironmentFile no serviço. Nunca é enviada ao navegador/APK nem devolvida nas rotas de status. Configuração do provedor em /opt/carinha-pc/conversa-config.json. A variável GEMINI_MODEL permite fixar um modelo em vez de usar alias.
|
||||
|
||||
## Memória e privacidade
|
||||
|
||||
O histórico e as lembranças permanecem no SQLite do Orange Pi. Ao escolher Gemini, até três pares completos de conversa e as lembranças são enviados ao Google junto da mensagem atual. Chamadas que falharam continuam visíveis no painel, mas não entram como perguntas pendentes no contexto. Mensagens antigas do executor local não são enviadas ao Gemini. O horário continua vindo do relógio do servidor.
|
||||
|
||||
O plano gratuito tem cotas e condições próprias de uso dos dados: https://ai.google.dev/gemini-api/terms . Integração REST documentada em https://ai.google.dev/gemini-api/docs/structured-output . Erros 429/503 aparecem no painel; não há troca silenciosa para outro provedor ou repetição automática de chamadas.
|
||||
|
||||
## Verificação
|
||||
|
||||
Respostas reais: “está bravo?” → “Eu? Nunca! Meus circuitos só sabem espalhar alegria por aí.” (1,23 s); música → “Adoro música! Os sons parecem pequenas engrenagens dançando na minha mente metálica.” (0,84 s). Valores são medições pontuais, sem garantia de latência. Respostas limitadas a JSON texto/gesto, validadas antes de renderizar; nenhum comando de motores.
|
||||
|
||||
A API retorna a resposta completa e o balão faz escrita animada; transmissão de tokens ainda não implementada. A personalidade automática por sensores continua no Qwen local; Gemini neste incremento controla a conversa por texto.
|
||||
|
||||
Rollback: selecione Local no painel. Para remover a credencial, remova o EnvironmentFile e o drop-in gemini.conf e reinicie o serviço após daemon-reload. Não apague memoria.db: ela contém histórico e lembranças.
|
||||
@@ -0,0 +1,9 @@
|
||||
# Repositório do Carinha
|
||||
|
||||
Código em https://git.roterizacao.cloud/PSAutomation/painel-ia-gemini, branch `carinha-orange-pi`, pasta `carinha/`.
|
||||
O repositório já contém outro sistema; sua branch principal foi preservada.
|
||||
|
||||
Credenciais, chave de assinatura Android, bases de conversa, logs, configurações do aparelho e arquivos gerados não são publicados.
|
||||
Modelos MediaPipe podem ser obtidos com `python obter-rastreamento.py`. As bibliotecas nativas llama.cpp ARM64 e a chave de assinatura Android precisam ser fornecidas separadamente para compilar o APK; permanecem na instalação atual. O servidor Python e a interface HTML estão no código versionado. Gemini usa GEMINI_API_KEY no ambiente do serviço.
|
||||
|
||||
Esta publicação não altera a instalação ativa no Orange Pi.
|
||||
@@ -0,0 +1,51 @@
|
||||
# Cérebro local — primeira integração
|
||||
|
||||
## Executor transferido para S10
|
||||
|
||||
Por solicitação do usuário, inferência agora em http://192.168.1.16:8101. Drop-in ia-s10.conf aponta CARINHA_IA_URL no serviço carinha-pc; modelo no Orange Pi desligado (carinha-ai.service disabled). API, configuração e distribuição de comandos continuam no Orange Pi. Decisão real via S10 levou 1,96 s, contra ensaio anterior de 21,96 s na placa; eventos e contexto podem diferir, portanto não é benchmark pareado de latência.
|
||||
|
||||
APK 0.6-ia-local instalado com bibliotecas ARM64 do llama.cpp. Ao abrir o app, CerebroLocal prepara modelo em files/qwen3-q4.gguf, baixando pela rota local /ia/modelo se ausente e validando SHA256. Executável fica em nativeLibraryDir, extraído pelo instalador; não executa código baixado da rede. Processo usa 2 threads, contexto 1024, um slot, porta LAN 8101. Modelo só é copiado uma vez. Fecha processo próprio ao destruir a Activity; precisa manter Carinha aberto e reabrir após reiniciar telefone. Não é serviço de boot ou foreground independente do rosto nesta versão.
|
||||
|
||||
Durante a migração, o executor de teste em /data/local/tmp/carinha-ai pode ser reutilizado se já estiver escutando 8101. A compilação e instalação do APK integrado passaram; inicialização pelo app requer confirmação via logs após o usuário reabrir. Logs Android: tag CarinhaIA; log do processo em files/ia-runtime.log. Endpoint privado do app visível pelo run-as para diagnóstico autorizado.
|
||||
|
||||
Para trocar IP, atualizar CARINHA_IA_URL e reiniciar carinha-pc. Não altera firmware nem configuração da rede. Porta do modelo não deve ser encaminhada no roteador para a internet. Para retornar à placa, remover apenas o drop-in ia-s10.conf, habilitar carinha-ai e reiniciar carinha-pc; configuração de personalidade é preservada.
|
||||
|
||||
As seções abaixo registram os ensaios e a configuração anterior no Orange Pi.
|
||||
|
||||
Implementado em 2026-10-05. Qwen3-0.6B quantizado Q4_K_M, llama.cpp b11404 (commit a3a1c4747). O modelo oficial é da Qwen; GGUF usado é quantização Unsloth, revisão 50968a4468ef4233ed78cd7c3de230dd1d61a56b. Arquivo 396705472 bytes, SHA256 ac2d97712095a558e31573f62f466a3f9d93990898b0ec79d7c974c1780d524a, conferido após download.
|
||||
|
||||
## Comparação medida
|
||||
|
||||
Mesmo modelo, CPU, dois threads, um ensaio por aparelho, prompt de 32 tokens e geração de 16:
|
||||
|
||||
| Aparelho | Recursos observados | Prompt tokens/s | Geração tokens/s |
|
||||
|---|---|---:|---:|
|
||||
| S10 SM-G973F universal9820 | 7,25 GiB total; 4,32 GiB disponíveis; 101 GB livres | 125,21 | 39,94 |
|
||||
| Orange Pi Zero3 | 969 MiB total; cerca de 716 MiB disponíveis antes da IA | 5,57 | 3,07 |
|
||||
|
||||
Conclusão: S10 tem significativamente mais capacidade neste ensaio. Cerca de 13x mais rápido em geração. São testes curtos, sem avaliação de temperatura, bateria ou carga longa. Não representam latência garantida de uma conversa completa.
|
||||
|
||||
Runtime Android foi testado via ADB em /data/local/tmp/carinha-ai, sem iniciar aplicativo pelo comando am start. Não está incorporado ao APK nem é serviço Android persistente nesta etapa. Não confundir benchmark com executor de produção no telefone. Uma futura integração nativa pode oferecer esse executor atrás da API central, mantendo troca de aparelhos. Nesta entrega o cérebro ativo continua no Orange Pi conforme preferência inicial.
|
||||
|
||||
## Instalação ativa
|
||||
|
||||
- /opt/carinha-ai/models/qwen3-0.6b-q4.gguf
|
||||
- Runtime /opt/carinha-ai/llama-b11404
|
||||
- carinha-ai.service habilitado no boot; endpoint restrito 127.0.0.1:8101.
|
||||
- Contexto 1024, um slot, dois threads, modo de pensamento desativado; prioridade Nice=10.
|
||||
- Aproximadamente 581 MB de memória contabilizada pelo serviço no ensaio; inclui páginas de arquivo e buffers. Sistema reportou cerca de 587 MiB disponíveis e 107 MiB swap usada depois dos testes/instalação.
|
||||
- Caso real: saudacao -> surpreso, resposta JSON validada, 21,96 segundos. A decisão real no Orange Pi é lenta; animações e controles do app continuam independentes.
|
||||
|
||||
## Personalidade
|
||||
|
||||
Painel principal: seção Personalidade · IA local. Ativar cérebro, escolher evento e Testar reação. Configuração persistente em /opt/carinha-pc/ia-config.json. Começa desativada. GET /ia/status mostra processamento, último gesto e erro; POST /ia/config {ativo:true}; POST /ia/evento {evento:"saudacao"}.
|
||||
|
||||
Eventos aceitos: som, movimento, saudacao, sozinho. Observação automática usa telemetria apenas com app online, acordado, sensores ativos. Intervalo mínimo 20 s entre inferências automáticas; curiosidade quando sozinho após 60 s. Memória curta de seis gestos por sessão, sem gravação de áudio ou vídeo. Uma inferência por vez. Modelo recebe somente evento e histórico curto, não imagens.
|
||||
|
||||
Modelo decide entre piscar, piscadinha, feliz, surpreso, coracao, olhar_esq, olhar_dir, olhar_baixo. JSON restrito por schema e validado novamente pelo servidor. Nenhum comando de pulso/motor permitido. Não é visão por modelo, reconhecimento de voz, conversa falada nem um controlador do braço. Desligar personalidade invalida a inferência em andamento antes de enfileirar ações. Uma expressão só entra na fila se celular ainda estiver conectado e acordado.
|
||||
|
||||
Validação: checksum, executáveis ARM nos dois aparelhos, benchmark real, inferência estruturada real, testes da lista de intenções e 12 regressões do servidor. O personagem físico depende do app estar aberto e conectado; resposta facial ainda requer observação do usuário.
|
||||
|
||||
Recuperação: desativar personalidade pelo painel; systemctl disable --now carinha-ai libera executor; preservar modelo e ia-config.json. Servidor e controles de servos continuam carinha-pc em 8100. Logs: journalctl -u carinha-ai. Os arquivos do servidor antes da IA permanecem no workspace e backups de etapas anteriores.
|
||||
|
||||
Fontes: https://huggingface.co/Qwen/Qwen3-0.6B ; https://huggingface.co/unsloth/Qwen3-0.6B-GGUF ; https://github.com/ggml-org/llama.cpp/releases/tag/b11404
|
||||
@@ -0,0 +1,34 @@
|
||||
# Servidor no Orange Pi Zero 3
|
||||
|
||||
Implantação em 2026-10-05. IP atual: 192.168.1.35.
|
||||
|
||||
- Painel: http://192.168.1.35:8100/painel
|
||||
- Diretório: /opt/carinha-pc
|
||||
- Serviço: carinha-pc.service, habilitado para iniciar no boot.
|
||||
- Sistema: Armbian Debian 13, Python 3.13.5, arquitetura aarch64.
|
||||
- Servidor anterior preservado: carinha-web.service, porta 8099.
|
||||
- Servidor do PC parado por solicitação do usuário. Arquivos preservados para recuperação. Orange Pi é a instalação ativa e suas configurações são a referência. iniciar.bat no PC agora somente abre o painel remoto.
|
||||
|
||||
O pacote inclui servidor, páginas, configurações, modelos locais de rastreamento e APK público. Não inclui chaves de assinatura ou SDK Android. SHA256 do pacote inicial: 6cc15c3395611f95a0a5b156d9d5f475273f59c2049f3a7ccd9f5e5da7701296.
|
||||
|
||||
## Celular
|
||||
|
||||
No Carinha, segure a tela, escolha Mudar o servidor e informe http://192.168.1.35:8100. O botão de conexão ADB do painel foi criado para o servidor Windows; não é o caminho de conexão nesta instalação Linux. O rastreamento visual continua sendo calculado no navegador do PC, enquanto o Orange Pi hospeda arquivos, configurações e sinalização.
|
||||
|
||||
## PCA9685
|
||||
|
||||
Ativado overlay i2c3-ph em /boot/armbianEnv.txt, preservando user_overlays=tft35. Reinício realizado. Barramento externo confirmado em /dev/i2c-2, controlador 5002c00.i2c. Não usar os barramentos internos PMIC ou HDMI.
|
||||
|
||||
Leitura sem configurar PWM: endereço 0x40 respondeu MODE1=0x11, MODE2=0x04, PRE_SCALE=0x1e. Esses valores não significam que a frequência já está adequada para servo. Diagnóstico: python3 /opt/carinha-pc/verificar-pca.py /dev/i2c-2.
|
||||
|
||||
Ligações: pino físico 1 (3,3 V) para VCC; 6 para GND; 3 para SDA; 5 para SCL. V+ dos servos recebe fonte externa, com terra comum. Usuário informou MG996R, fonte de 6 V, canal provavelmente 1. Corrente da fonte e numeração do canal ainda aguardam confirmação. Nenhum pulso de movimento foi enviado nesta etapa.
|
||||
|
||||
## Verificação e retorno
|
||||
|
||||
Após reinício: serviços novo e anterior ativos, /app/health respondeu versão 0.5, /painel retornou HTTP 200 e modelo hands.task foi servido integralmente (7819105 bytes).
|
||||
|
||||
Para parar a instalação nova: systemctl disable --now carinha-pc. A antiga permanece em 8099. Para retornar o celular ao PC, use http://192.168.1.15:8100 no menu Mudar o servidor.
|
||||
|
||||
Backup do boot antes do I²C: /boot/armbianEnv.txt.before-carinha-i2c-20261005. Para desfazer somente esta alteração, restaure esse arquivo para /boot/armbianEnv.txt e reinicie. Preserve alterações posteriores caso existam.
|
||||
|
||||
Logs: journalctl -u carinha-pc -n 100. Reinício do servidor: systemctl restart carinha-pc.
|
||||
@@ -0,0 +1,21 @@
|
||||
# Controle pelo PC Implementation Plan
|
||||
|
||||
> Execução inline nesta sessão, com executing-plans. O usuário autorizou implementar o desenho.
|
||||
|
||||
**Goal:** Controlar rosto, comportamento e câmera frontal do S10 pelo navegador do PC.
|
||||
**Architecture:** Estender servidor e painel existentes; compartilhar captura Camera2 entre movimento e transmissão JPEG; aplicar configurações na página em tempo real.
|
||||
**Tech Stack:** Python biblioteca padrão, HTML/CSS/JavaScript, Java Android Camera2, ferramentas Android locais.
|
||||
**Spec:** DESIGN.md
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- Windows, porta 8100, Android min API 21. Sem placa, sem novas dependências de execução.
|
||||
- Rede local, sem gravação, imagem recente, no máximo um quadro pendente.
|
||||
- Preservar rotas de gestos e aparência. Painel não deve consumir a fila do celular.
|
||||
|
||||
## Tarefas
|
||||
|
||||
1. [ ] Escrever `tests/test_controle_pc.py`, usando servidor HTTP real com porta efêmera. Verificar POST/GET configuração, persistência em arquivo temporário, rejeição de valores inválidos, telemetria recente, JPEG desativado/expirado, fila preservada. Rodar `python -m unittest discover -s tests` e confirmar falhas pelas rotas ausentes. Implementar `controle_pc.py` e integrar Handler em `kiosk-server.py`, repetir testes.
|
||||
2. [ ] Escrever teste JVM `tests/YuvFrameTest.java`: quadro YUV 2x2 com strides diferentes deve virar NV21 `[16,32,48,64,150,100]`. Compilar contra `YuvFrame.java` e observar falha antes de implementar conversor. Criar `ControleRemoto.java` para consultar preview e enviar JPEG com timeouts e uma única thread. Integrar ciclo de vida e captura no MainActivity. Compilar APK com SDK/JDK locais e verificar assinatura.
|
||||
3. [ ] Ampliar painel com câmera, conectividade, ajustes e conexão ADB. Manter rostos e gestos existentes. Aplicar config na carinha e enviar telemetria a cada segundo. Verificar controles com navegador e resposta efetiva no aparelho.
|
||||
4. [ ] Iniciar servidor local oculto, instalar APK no S10 conectado, abrir app com servidor `http://192.168.1.15:8100`. Testar imagem JPEG recente, rosto/cor alterados, configuração confirmada, desligar preview sem interromper rosto. Atualizar APP.md e launcher. Entregar atalho local e documentação em outputs.
|
||||
@@ -0,0 +1,11 @@
|
||||
# Rastreamento local no PC — desenho aprovado em 05/10/2026
|
||||
|
||||
O vídeo WebRTC já recebido no painel será analisado por MediaPipe FaceDetector e HandLandmarker em um Web Worker. Modelos e WASM ficam no projeto, sem enviar imagens à internet. Um quadro reduzido por vez, sem fila acumulada, limita custo de CPU e atraso. Rosto: caixa e pontos principais; mãos: 21 pontos e conexões dos dedos. Canvas acompanha o vídeo respeitando barras e redimensionamento.
|
||||
|
||||
Controles persistentes e independentes: rastrear rosto, rastrear mãos, olhos acompanharem, mostrar rastreamento. Iniciar habilitado conforme pedido; câmera/sensores/sono mantêm precedência. Rastreamento no PC depende de painel aberto e transmissão ligada. Sem isso, continua detector simples do Android.
|
||||
|
||||
Uma mão detectada tem prioridade para o alvo; sem mão, rosto. Escolha estável entre candidatos próximos evita saltos. Pacote compacto de alvo normalizado via RTCDataChannel não ordenado, sem retransmissão; nenhum pacote passa pela fila de gestos. Dados antigos expiram em 350 ms e o detector simples retoma. Seguir alvo estático não deve produzir sustos ou impedir sono; movimento real do alvo pode manter atividade.
|
||||
|
||||
O detector simples troca 80/100 ms por aproximadamente 33 ms, elimina aquecimento excessivo e aumenta a resposta dos olhos de 25% para 65% por amostra. Animações existentes e sono continuam funcionando. Inferência adapta frequência até 20 Hz, sem bloquear reprodução. Erros dos modelos aparecem no painel e não derrubam vídeo.
|
||||
|
||||
Testar seleção/prioridade/normalização, expiração, inferência real com imagens de referência, canvas e canais WebRTC; compilar e instalar APK 0.5. Medir desempenho real do PC/S10 separadamente dos testes simulados.
|
||||
@@ -0,0 +1,15 @@
|
||||
# Rastreamento local — plano de implementação
|
||||
|
||||
**Objetivo:** detectar rosto/mãos no PC, mostrar marcações e orientar os olhos com menor atraso.
|
||||
**Arquitetura:** worker MediaPipe local, canvas no painel, alvo via DataChannel e ponte Java/rosto.
|
||||
**Stack:** Python HTTP existente, JavaScript/WASM MediaPipe, Android Java/WebView.
|
||||
**Desenho:** RASTREAMENTO-DESIGN.md. Projeto separado existente; sem repositório Git.
|
||||
|
||||
- [x] 1. Testes falhando: configurações de rastreamento, seleção de alvo, coordenadas e expiração.
|
||||
- [x] 2. Modelos/arquivos MediaPipe versionados localmente, licença/proveniência e script de obtenção.
|
||||
- [x] 3. Worker com FaceDetector/HandLandmarker e um quadro pendente; canvas e controles independentes no painel.
|
||||
- [x] 4. DataChannel painel→Android; validar alvo/configuração; seguir sem susto quando estático; expirar em 350 ms.
|
||||
- [x] 5. Detector simples com análise a cada quadro novo, resposta mais rápida; manter sono e sensores.
|
||||
- [x] 6. Verificar HTTP/Node/Chromium com inferência real e vídeo, compilar/instalar APK e atualizar documentação.
|
||||
|
||||
Cada etapa implementada após prova de falha pertinente. Validação: unittest, Node, Playwright, build-apk.py e instalação ADB. Atualização do servidor apenas após inspeção de PID/caminho. Sem abrir app via ADB por restrição já encontrada nesta sessão.
|
||||
@@ -0,0 +1,22 @@
|
||||
# Rosto e mãos no PC — versão 0.5
|
||||
|
||||
Abra o painel, ligue a transmissão e mantenha a aba aberta. Os quatro controles sob o vídeo começam habilitados: **Rastrear rosto**, **Rastrear mãos**, **Olhos acompanharem o alvo** e **Mostrar rastreamento no vídeo**. Desmarcar as marcações mantém a detecção; desmarcar o acompanhamento mantém a visualização. Desligar ambos os rastreadores encerra o processamento.
|
||||
|
||||
Azul indica a caixa e pontos principais do rosto; verde mostra os 21 pontos e conexões das mãos; amarelo indica o alvo. Mãos têm prioridade sobre rosto. Com múltiplos candidatos, mantém o candidato próximo ao alvo anterior. O painel exibe quantidade de detecções, frequência de análise e tempo de inferência. Não reconhece identidade nem interpreta gestos como comandos.
|
||||
|
||||
O PC usa MediaPipe em Web Worker com um quadro reduzido até 640 pixels de largura por vez, sem fila acumulada. Frequência adaptativa até 20 análises/s. Modelos, JS e WASM são locais: `vendor/mediapipe`, runtime `@mediapipe/tasks-vision` 0.10.32. `obter-rastreamento.py` permite obter os mesmos artefatos oficiais novamente; `PROVENIENCIA.json` registra URLs, versão, integridade npm e hashes. A execução não envia imagens à internet. CPU, distância, iluminação, imagem recebida e resolução influenciam a detecção.
|
||||
|
||||
Alvo normalizado via DataChannel WebRTC não ordenado e sem retransmissões, validado nas pontes JS e Java. Sequência crescente evita aceitar pacotes fora de ordem; alvo expira após 350 ms. Nenhum alvo passa pela fila de gestos HTTP. Sem detecção, sem painel ou sem vídeo, segue o detector simples no celular. A câmera desligada globalmente ou durante sono impede o rastreamento. Presença estática não força despertar nem mantém o rosto acordado; movimento real do alvo conta como atividade. Mantidos os controles de reação aos sons/movimento.
|
||||
|
||||
Detector simples: leitura a cada quadro novo (~33 ms quando a câmera permite), aquecimento de três quadros e resposta dos olhos de 65% por amostra. Movimento breve segura a posição por 200 ms para não oscilar ao centro entre quadros. A câmera ainda precisa fornecer quadros e a rede/encoder ainda acrescentam atraso. Combinações de câmera indisponíveis voltam efetivamente à qualidade automática, incluindo adaptação de bitrate/resolução.
|
||||
|
||||
## Validação
|
||||
|
||||
- 12 testes HTTP: persistência e controles independentes, além dos recursos anteriores.
|
||||
- Node: prioridade do alvo, ajuste de coordenadas às barras do vídeo, validação e expiração; adaptação de qualidade.
|
||||
- Chromium: inferência real encontrou um rosto e duas mãos em imagens de referência Google; os pontos foram renderizados e conferidos visualmente. Teste bloqueou acessos externos durante execução.
|
||||
- Chromium: acompanhamento em uma amostra, perda de alvo liberando detector simples, sono respeitado, toggles e layout desktop/mobile.
|
||||
- WebRTC real entre páginas Chromium com câmera simulada: ~30 FPS, transporte de alvo e limpeza via DataChannel, seleção de qualidade, fallback e reconexão.
|
||||
- APK 0.5: build e assinatura verificados. Medição final de atraso no S10 com a mão do usuário ainda depende do teste físico.
|
||||
|
||||
Fontes: [Hand Landmarker Web](https://developers.google.com/edge/mediapipe/solutions/vision/hand_landmarker/web_js), [Face Detector Web](https://developers.google.com/edge/mediapipe/solutions/vision/face_detector/web_js). Imagens de referência usadas nos testes: `https://storage.googleapis.com/mediapipe-assets/portrait.jpg` e `https://storage.googleapis.com/mediapipe-assets/right_hands.jpg`, guardadas em `work/tracking-fixtures`.
|
||||
@@ -0,0 +1,65 @@
|
||||
# Registro local
|
||||
|
||||
## 04/10/2026
|
||||
|
||||
- Lidos APP.md, servidor, painel e código Android do projeto original.
|
||||
- Confirmado ADB Wi-Fi com Galaxy S10 (`192.168.1.16:5555`). IP do PC: `192.168.1.15`.
|
||||
- Aprovado desenho de controle pelo PC com captura frontal compartilhada com o detector de movimento.
|
||||
- Criado projeto independente `carinha-pc`; documentação e testes transferidos para ele.
|
||||
- Primeira execução dos cinco testes HTTP falhou nas rotas ausentes (404), como esperado. Nenhuma implementação nova aplicada ao original.
|
||||
|
||||
### Implementação e resultados
|
||||
|
||||
- Servidor Windows independente, painel na porta 8100 e atalhos `iniciar.bat` / `servir-local.bat`.
|
||||
- Configuração persistente de comportamento; telemetria do celular com prazo de cinco segundos; JPEG recente, sem gravação e sem expor código/chave pelo servidor HTTP.
|
||||
- Camera2 compartilhada entre análise e transmissão. Conversão YUV colorida, orientação do sensor, até cinco envios por segundo, um quadro pendente e timeouts de rede.
|
||||
- Painel responsivo com câmera, sensores, conexão ADB, rosto/cor/gestos e ajustes. Prévia do rosto não consome a fila do aparelho nem reproduz áudio.
|
||||
- Corrigida cor dos olhos que voltava para ciano após entrar em repouso.
|
||||
- A pedido do usuário: brilho de janela 70% ativo / 8% repouso, 30 segundos sem atividade. Sons/movimento/comandos restauram brilho. Gestos espontâneos não impedem economia. Preferências ajustáveis no painel.
|
||||
- Sete testes HTTP reais passaram. Teste de navegador passou com volume/sono remotos, rosto/cor persistentes, toggle da câmera e ausência de overflow em 390 px.
|
||||
- Testes JVM de NV21 com strides e decisão de brilho passaram.
|
||||
- APK `0.2-pc` compilado, assinatura verificada e atualização instalada no Galaxy S10 com resposta ADB `Success`.
|
||||
- Launcher verificado; consulta de saúde usa 127.0.0.1 para evitar atraso de resolução IPv6 de localhost no Windows.
|
||||
- Encerrados servidores temporários nas portas 8099 e 18099. Mantido somente servidor do projeto na porta 8100.
|
||||
|
||||
### Pendência física
|
||||
|
||||
A ferramenta rejeitou `adb shell am start` com `blocked by policy`, inclusive após pedido explícito do usuário. Não foi possível abrir/apontar a Activity nesta sessão. A instalação foi aceita e concluída; câmera ao vivo, orientação e brilho físico ainda exigem teste no S10 com o app aberto em `http://192.168.1.15:8100`. O painel oferece **Conectar e abrir o app** para execução local pelo usuário. O guia também documenta o comando manual.
|
||||
|
||||
Estado: implementação e testes automatizados concluídos; validação física pendente.
|
||||
|
||||
### Diagnóstico após abrir o app
|
||||
|
||||
ADB confirmou S10 conectado em `192.168.1.16:5555`. Logcat confirmou microfone e detector nativo ativos, mas `CarinhaPC` tenta `192.168.1.15:8099` (endereço antigo persistido). A página está em `file:///android_asset/carinha.html`, pois caiu para a cópia interna. O servidor 8100 responde normalmente e ainda não recebeu telemetria. Correção: no menu de toque longo do app, mudar servidor para `http://192.168.1.15:8100`.
|
||||
|
||||
## 05/10/2026 — conexão física confirmada
|
||||
|
||||
Após o usuário mudar o servidor no app, `/app/status` confirmou `online=true`, câmera e microfone ativos, rosto `miudo`, configurações recebidas e brilho ativo 0.70. `/camera/frame` retornou HTTP 200, `image/jpeg`, 19.618 bytes, com quadros recentes. Captura e transmissão funcionam no S10 com o rosto aberto. Ainda não foi verificada visualmente a orientação da imagem nem observada a transição física para brilho de repouso.
|
||||
|
||||
### Vídeo automático e elementos do rosto
|
||||
|
||||
- Usuário pediu vídeo fluido, qualidade automática e controles para boca/sobrancelhas. Aprovado modo automático como padrão.
|
||||
- Implementados WebRTC emissor no app e receptor no painel. Nenhuma biblioteca Android nova: WebView auxiliar embutida, ponte Java limitada e sinalização local Python. Vídeo sem gravação passa diretamente entre os pares.
|
||||
- Qualidade adapta resolução/bitrate com estatísticas, alvo 30 fps; painel informa fps reais. Detecção de movimento permanece ativa na própria captura.
|
||||
- Boca e sobrancelhas controladas independentemente, com expressões.
|
||||
- Dez testes HTTP passaram. Teste Node de adaptação passou. Teste do navegador cobriu boca desligada/sobrancelhas ligadas. Teste WebRTC real com câmera simulada a 30 fps recebeu 63 quadros em 2,2 segundos e mediu 30 fps.
|
||||
- Corrigida configuração do dispositivo simulado: padrão Chromium fornecia 20 fps; teste agora solicita explicitamente `fps=30`, sem alterar a expectativa de fluidez.
|
||||
- APK 0.3 compilado, assinatura verificada e instalado no S10 (`Success`). Servidor reiniciado com rotas de sinalização.
|
||||
- Solicitado ao usuário reabrir o Carinha e recarregar o painel. Validação dos fps reais no S10 pendente de reabertura.
|
||||
## 05/10/2026 — versão 0.4, sensores e seleção de câmera
|
||||
|
||||
- Controles globais de microfone/câmera e permissões independentes para o sono. Padrão: só microfone durante sono. Captura interrompida de verdade; vídeo respeita câmera desligada e reconecta ao acordar.
|
||||
- Seleção frontal/traseira, resolução e FPS no painel e menu Android. Automático por padrão; máximo consulta capacidades; modos manuais indisponíveis voltam ao automático com aviso. Removido teto fixo de 720p/30 na captura RTC.
|
||||
- Validados 11 testes HTTP, adaptação em Node, política de sono em JVM, painel desktop/mobile e WebRTC Chromium (~30 FPS com câmera simulada), mudança de resolução, fallback de FPS e desligamento/reconexão.
|
||||
- APK 0.4 compilado, assinatura verificada e instalado no S10 via ADB (`Success`). Servidor reiniciado na porta 8100, `/app/health` confirma 0.4; padrão automático e só microfone no sono confirmados no endpoint.
|
||||
- 4K/60 no hardware ainda não medido. Reabrir app após instalação e atualizar painel com Ctrl+F5.
|
||||
|
||||
## 05/10/2026 — versão 0.5, rastreamento de rosto/mãos
|
||||
|
||||
- Modelos MediaPipe e runtime 0.10.32 salvos localmente com licença e hashes. Worker dedicado detecta rosto e mãos com um quadro pendente, reduzido até 640 px. Inferência testada sem acesso externo.
|
||||
- Quatro controles habilitados por padrão sob o vídeo: rosto, mãos, acompanhamento dos olhos, mostrar marcações. Caixa/pontos de rosto azuis, esqueleto de mão verde, alvo amarelo. Regras de câmera/sono mantidas.
|
||||
- Alvos seguem por RTCDataChannel, sem fila de gestos; validação, sequência e expiração de 350 ms. Mão tem prioridade sobre rosto. Detector simples ~33 ms por quadro novo, suavização dos olhos de 65%, aquecimento de três quadros.
|
||||
- Corrigido fallback de qualidade manual indisponível para realmente usar adaptação automática.
|
||||
- Validados 12 testes HTTP, Node, Chromium desktop/mobile, inferência real (1 rosto e 2 mãos em imagens oficiais), overlay e toggles, sono, expiração e transporte de alvo WebRTC. Vídeo simulado ~30 FPS. Marcações conferidas visualmente em captura de teste.
|
||||
- APK 0.5 compilado/assinado e instalado no S10 (`Success`). Servidor reiniciado; `/app/health` confirma 0.5 e os quatro controles ativos. Reabrir app e atualizar painel com Ctrl+F5. O atraso físico do aceno ainda precisa de avaliação com o aparelho.
|
||||
|
||||
@@ -0,0 +1,15 @@
|
||||
# Sensores e câmeras — versão 0.4
|
||||
|
||||
No painel, os controles **Microfone ligado** e **Câmera ligada** interrompem a captura nativa ao serem desativados. Reagir aos sons/movimento controla o comportamento separadamente. Desligar a câmera também impede a transmissão de vídeo.
|
||||
|
||||
Durante o sono, cada sensor precisa estar ligado globalmente e autorizado para o sono. O padrão mantém apenas o microfone. O som pode acordar o rosto se a reação aos sons estiver habilitada. Com ambos desligados, acorde pelo gesto remoto ou toque. Desativar a câmera no sono interrompe o vídeo e ele reconecta ao acordar, se a transmissão continuar habilitada.
|
||||
|
||||
Segure a tela do Android: **Sensores acordado / dormindo** e **Camera e qualidade do video**. As alterações são enviadas ao servidor do PC e persistidas em `app-config.json`; precisam da conexão com o servidor. O painel acompanha os mesmos ajustes.
|
||||
|
||||
Escolha frontal/traseira, resolução automática, máxima disponível ou 480p/720p/1080p/4K/8K; FPS automático, máximo disponível ou 15/24/30/60/120/240. São pedidos de captura, não uma garantia de suporte. Combinações manuais não aceitas pelo WebView retornam para captura automática e exibem aviso. Não há limite fixo de 720p/30 no capturador; máximo consulta `getCapabilities()` da câmera selecionada. Os máximos de resolução e FPS podem não ser simultâneos.
|
||||
|
||||
O padrão automático tenta 1080p/30 e adapta a resolução/bitrate transmitidos à rede e ao desempenho. Manual usa a captura realmente obtida e não impõe redução própria de resolução, embora o encoder WebRTC também possa adaptar o vídeo. A resolução/FPS recebidos aparecem no painel; capacidade do aplicativo de câmera Samsung pode exceder a disponível no WebView/WebRTC.
|
||||
|
||||
A câmera usada para detectar movimento segue a seleção frontal/traseira. Microfone mede apenas intensidade; câmera mede diferenças entre imagens. Não há reconhecimento de voz, objetos ou rostos nem integração de acelerômetro, giroscópio, luz ou proximidade.
|
||||
|
||||
Validação: testes de persistência/validação, política de sensores em JVM e Chromium com câmera simulada para transmissão, mudança de resolução, fallback de FPS indisponível, desligamento da câmera e reconexão. 4K/60 físico ainda requer medição no aparelho.
|
||||
@@ -0,0 +1,31 @@
|
||||
# Aba de testes de servos
|
||||
|
||||
## Controle ao vivo
|
||||
|
||||
Opção disponível acima dos cartões, desmarcada ao abrir a página. Ativar a opção não movimenta: arrastar um deslizador envia o pulso respeitando os limites salvos. No máximo 10 solicitações por segundo, uma em andamento por vez; valores intermediários são substituídos pela posição mais recente. O watchdog do servidor desliga o canal até cerca de 2,1 segundos após o último comando recebido.
|
||||
|
||||
Desmarcar Controle ao vivo ou clicar Desligar todos cancela a fila, aguarda a solicitação em andamento e desliga os canais. Ocultar a página também solicita desligamento. Falha de rede continua coberta pelo watchdog. Alterações não salvas bloqueiam o modo. O motor não fornece confirmação da posição física.
|
||||
|
||||
Verificado no navegador com API simulada: ativação sem movimento, arraste desativado sem comandos, frequência limitada, entrega da última posição, cancelamento ao parar e bloqueio com configurações não salvas. Testes da página original continuam passando. Movimento físico depende da observação do usuário.
|
||||
|
||||
Correção em 2026-10-05: removida a escrita de zero em ALL_LED_OFF_H após escrever o pulso individual. Esse registrador replica o byte nos 16 canais, sobrescrevendo o pulso (1500 µs acabava com 51 ticks em vez de 307) e retirando o desligamento dos outros canais. Teste de regressão emula essa replicação e confirma o valor correto e isolamento dos canais. Correção instalada e serviço reiniciado. Movimento físico ainda precisa ser observado pelo usuário.
|
||||
|
||||
Disponível em http://192.168.1.35:8100/servos e no link Servos do painel. Instalada no Orange Pi em 2026-10-05.
|
||||
|
||||
Começa com seis cartões, canais 0–5, e permite adicionar até 16. Cada cartão configura nome, canal físico, mínimo, máximo e centro em microssegundos. Canal 1 corresponde inicialmente ao cartão Servo 2: o nome do cartão não é a numeração da placa.
|
||||
|
||||
Configurações são gravadas em /opt/carinha-pc/servos.json ao clicar Salvar configurações. Enquanto há alterações não salvas, os testes ficam bloqueados. Abrir a página, mover o slider ou salvar não envia movimento. Não existe leitura da posição real do eixo.
|
||||
|
||||
Testar por 2 s envia o pulso escolhido; Testar centro envia o centro configurado. O backend desliga automaticamente esse canal em até aproximadamente 2,1 segundos. Desligar todos os sinais desliga os 16 canais. Isso não corta a fonte externa e pode remover a sustentação de um braço montado: nesta etapa usar braço apoiado ou servo sem carga. Não é botão de emergência elétrica.
|
||||
|
||||
Limites iniciais 1400–1600 µs, centro 1500 µs; limites absolutos aceitos pela API 1000–2000 µs. Não ampliar sem calibração da montagem. A duração máxima não limita velocidade nem esforço mecânico. Nenhuma sincronização de servos pareados nesta etapa.
|
||||
|
||||
PCA9685 em 0x40, /dev/i2c-2, configurado por Environment=CARINHA_I2C=/dev/i2c-2 no drop-in /etc/systemd/system/carinha-pc.service.d/i2c.conf. O driver usa biblioteca padrão Linux, 50 Hz aproximados (prescale 121; oscilador nominal 25 MHz). Somente o primeiro teste configura a frequência: desliga primeiro os canais antigos antes de liberar o canal solicitado. Inicialização do servidor não envia pulsos.
|
||||
|
||||
O servidor Windows exibe configurações mas não controla hardware. Usar a aba hospedada no Orange Pi. Nenhum motor foi acionado nos testes automatizados da implantação. Alimentação informada: 6 V; corrente da fonte ainda não confirmada. Dimensionar a fonte conforme os motores antes de testar carga ou vários simultaneamente.
|
||||
|
||||
Verificado: testes de validação e persistência, até 16 canais, duplicatas rejeitadas, duração máxima, sequência de inicialização, regressão do servidor (12 testes), página real no navegador desktop/mobile, rejeição de pulso inválido e origem externa. Pendentes: movimento físico, calibração e mapeamento do braço conforme os arquivos que o usuário fornecerá.
|
||||
|
||||
Arquivos: servos.py, servos.html, servos.js. API: GET /servos/status; POST JSON /servos/config {servos:[...]}, /servos/mover {indice:0,pulso:1500}, /servos/parar {}. O índice é o cartão na lista, começando em zero; canal é configurável. Comandos inválidos recebem HTTP 400 e indisponibilidade I²C HTTP 503.
|
||||
|
||||
Retorno: parar serviço; restaurar kiosk-server.py e painel.html de /opt/carinha-pc/backup-servos-20261005; remover drop-in i2c.conf; systemctl daemon-reload; iniciar serviço. Preservar servos.json. O servidor anterior em 8099 permanece disponível.
|
||||
@@ -0,0 +1,56 @@
|
||||
# Treinamento e reações dinâmicas — 2026-10-05
|
||||
|
||||
## Visual sem frases e chuva de símbolos
|
||||
|
||||
Preferência aprovada: textos de conversa ficam apenas em /conversa; o celular exibe rosto e símbolos. Receitas antigas continuam válidas, mas suas legendas não são desenhadas. Música gera 16 notas caindo do topo; comemoração e carinho usam estrelas e corações. Café e ideia conservam um símbolo isolado, sem chuva. A chuva é curta, com posições/durações variadas e limpeza das partículas ao terminar ou substituir a reação. O prompt das novas receitas pede legenda vazia e símbolos coerentes com o assunto.
|
||||
|
||||
Teste em navegador confirmou 16 partículas, deslocamento vertical descendente, ausência de frase/balão e limpeza após o efeito. Reabra o app conectado para receber o HTML atualizado. Não gera novas imagens de figurinhas neste incremento.
|
||||
|
||||
Design aprovado: nova aba /treinamento, rotina e preferências, diário de conversas, resumo de uma hora, biblioteca de animações e feedback. É aprendizado por contexto; os pesos do Gemini não são treinados.
|
||||
|
||||
## Uso
|
||||
|
||||
1. Abra /treinamento e registre sua rotina ou converse no painel.
|
||||
2. Clique Criar reações agora. Gemini Flash Lite gera um resumo e três novas receitas de animação.
|
||||
3. Prévia anima o desenho dentro da aba. Mostrar no celular publica a reação; o app conectado consulta e renderiza. ACK do servidor não é confirmação visual do aparelho.
|
||||
4. Gostei/Não gostei ficam salvos. O próximo pedido de geração recebe as avaliações; o Gemini da conversa pode escolher entre as cinco últimas reações que não tenham avaliação negativa.
|
||||
5. Opcionalmente ative geração por hora. Está desligada por padrão. O servidor verifica a cada 30 segundos e gera após um intervalo de uma hora se houve nova conversa, sem movimentar motores. Abrir a aba não gera chamada. Reiniciar o serviço reinicia a contagem do intervalo.
|
||||
|
||||
## Diário e memória
|
||||
|
||||
treinamento.db no Orange Pi guarda rotinas, diário com horário, resumos e reações. Conversas são copiadas para o diário a partir da atualização; não retrodatamos conversas anteriores. O resumo usa até 200 mensagens da última hora e o último resumo. UI mostra 50 eventos e 30 reações; retenção: 2000 eventos, 100 reações e 100 resumos. Rotinas têm limite de 30 entradas, 300 caracteres cada, e também entram no contexto da conversa Gemini.
|
||||
|
||||
Atividades descritas pelo usuário são relatos; este diário não registra sensores ou ações físicas verificadas. O modelo pode cometer erros ao resumir. Apagar diário e resumos mantém rotinas e reações; apagar conversas e lembranças no painel também limpa diário/resumos. Rotinas podem ser apagadas individualmente.
|
||||
|
||||
## Renderização
|
||||
|
||||
Receitas contêm nome, motivo, legenda, símbolo e até seis passos. Cada passo define forma dos olhos e boca, cor de uma paleta, deslocamento limitado, escala e duração. O renderer usa o SVG existente, interpolação e símbolos animados. É composição procedural, não geração de imagens ou de código. Sobrancelhas seguem as opções e formas existentes do rosto. Receitas são validadas no servidor antes de salvar; o navegador também limita valores. Nenhum comando de servos é emitido.
|
||||
|
||||
O celular deve recarregar carinha.html para receber reacoes-render.js. Não há atualização de APK necessária no modo conectado. O fallback offline do APK antigo conserva as expressões anteriores.
|
||||
|
||||
## Verificação e limites
|
||||
|
||||
Gemini criou Comemoração, Dança Musical e Ideia Feliz a partir de uma conversa de teste. Em novo pedido, escolheu Dança Musical e publicou a receita para o app (2,58 s). Navegador verificou a prévia real e layout em 390 px, sem erros JS. Testes de validação, persistência, gatilho simulado de uma hora e catálogo passaram. A passagem física de uma hora e a exibição no celular não foram verificadas diretamente nesta sessão.
|
||||
|
||||
Dados de contexto são enviados ao Google quando Gemini é usado. A chave permanece no servidor. Geração manual/periódica consome cota; falhas são apresentadas na aba. As reações criadas inicialmente são dados de teste, avaliáveis/aproveitáveis pelo usuário.
|
||||
|
||||
Backup dos arquivos anteriores: /opt/carinha-pc/backup-treinamento-20261005. Para desativar geração periódica, desmarque a opção. Configurações do braço e dos servos foram preservadas.
|
||||
|
||||
## Ajuste visual aprovado
|
||||
|
||||
A queda foi substituida por simbolos em posicoes aleatorias que aparecem e desaparecem suavemente. Notas, estrelas e coracoes mantem posicao fixa durante cada efeito, com tempos diferentes e brilho leve. Teste do navegador confirmou ausencia de queda, animacao de opacidade e limpeza ao final. Atualize a previa e reabra o app conectado.
|
||||
|
||||
## Icones nos olhos
|
||||
|
||||
Ideia e cafe agora aparecem dentro de cada olho, acompanhando a posicao e a escala do desenho. O simbolo expira junto com a reacao. Teste do navegador confirmou dois icones contidos nos olhos, ausencia de legenda e restauracao ao terminar; efeito de simbolos piscando tambem passou. Reabra o app para atualizar o renderer do rosto.
|
||||
|
||||
A bolinha de brilho fica oculta enquanto ha icone dentro dos olhos e volta ao desenho normal ao terminar. Teste de navegador confirmou ocultacao e restauracao nos dois olhos.
|
||||
|
||||
## Refinamento visual — 05/10/2026
|
||||
Prévia ampliada para 360 px no computador, controles agrupados ao lado, textos mais curtos e botão Desenhar e mostrar destacado. Opções automáticas e registros ficam em seções expansíveis. O rosto mantém fundo preto, com halo discreto na cor dos olhos e interpolação mais suave dos movimentos. Ícones e figurinhas nos olhos continuam ocultando o brilho branco da íris.
|
||||
Validação: testes Chromium de prévia, SVG dentro e fora dos olhos, restauração do brilho e layout móvel de 390 px passaram sem erros JavaScript. A aparência física no celular depende de recarregar a tela HTML; não exige APK novo.
|
||||
|
||||
|
||||
### IP e confirmação da recarga
|
||||
O painel detecta o IP do celular pela origem da telemetria e preenche o endereço do servidor usado no navegador. Cada recarga recebe um identificador; a tela mostra Tela atualizada por quatro segundos e devolve o identificador na telemetria. O painel só informa sucesso após essa confirmação; após 12 segundos sem resposta, orienta reabrir o app. Uma tela HTML antiga precisa ser reaberta uma vez para receber o novo comando. Testes: 12 verificações HTTP, navegação única de recarga e teste Chromium de IP e aviso passaram. IP real recebido do celular: 192.168.1.16.
|
||||
|
||||
@@ -0,0 +1,35 @@
|
||||
# Vídeo contínuo com qualidade automática
|
||||
|
||||
Desenho aprovado em 05/10/2026: vídeo contínuo, qualidade automática como padrão, buscando 30 fps. Boca e sobrancelhas com controles independentes.
|
||||
|
||||
## Integração
|
||||
|
||||
O painel recebe uma faixa de vídeo via WebRTC. O servidor Python troca apenas sinalização (`/rtc/session`, `/rtc/send`, `/rtc/poll`); o vídeo comprimido passa diretamente pela rede local entre Android e navegador. Sem serviços externos de STUN/TURN e sem gravação. Cada vez há um painel receptor ativo; abrir outro substitui a sessão anterior.
|
||||
|
||||
O Android usa uma WebView auxiliar com página embutida `transmissao.html`, em contexto `file://` já usado no app para câmera. Ela permanece anexada à Activity atrás do rosto e recebe somente a permissão de vídeo. A ponte Java fornece sinalização HTTP, telemetria e movimento; não há permissão de acesso remoto a arquivos pela WebView.
|
||||
|
||||
Durante a transmissão, o detector Camera2 anterior é suspenso para liberar a lente. A página de vídeo calcula movimento numa amostra 176×132, dez vezes por segundo, e manda o mesmo sinal à carinha. Sem transmissão, o detector nativo volta. Microfone, rosto e economia de brilho continuam funcionando. Sair do primeiro plano para câmera e conexão.
|
||||
|
||||
## Qualidade
|
||||
|
||||
Captura solicitada: até 1280×720 a 30 fps; fallback por restrição de formato em 640×480. O codec é negociado pelo WebRTC entre as capacidades dos aparelhos (não é forçado H.264). Prioridade `maintain-framerate`; os fps efetivos aparecem no painel.
|
||||
|
||||
Controle automático usa estatísticas reais do emissor. Congestionamento, atraso elevado ou fps baixo reduzem resolução/bitrate. Só sobe após quatro leituras estáveis, evitando oscilações. Tetos de bitrate: 2,5 / 1,3 / 0,6 Mb/s; fatores de escala: 1 / 1,5 / 2. A taxa de quadros alvo permanece 30. Esses valores são tetos, não garantia de resultado em qualquer rede/aparelho.
|
||||
|
||||
## Validação
|
||||
|
||||
- Testes HTTP verificam isolamento de sessão, mensagens preservadas por cursor e rejeição de sessões antigas.
|
||||
- Teste Node verifica redução automática e subida após estabilidade.
|
||||
- Teste `test_rtc_browser.py` usa câmera simulada de 30 fps e conexões WebRTC reais entre duas páginas Chromium. Resultado observado: 63 quadros em 2,2 segundos, painel 30 fps, 640×360.
|
||||
- Teste de navegador verifica ativação/desativação independente de boca e sobrancelhas.
|
||||
- Compilação/verificação da assinatura Android necessárias antes de atualizar.
|
||||
- Validação no S10 exige reabrir o app após a instalação e recarregar o painel.
|
||||
|
||||
## Referências técnicas
|
||||
|
||||
- [RTCRtpSender.setParameters](https://developer.mozilla.org/en-US/docs/Web/API/RTCRtpSender/setParameters): bitrate, escala e prioridade de degradação.
|
||||
- [RTCPeerConnection.getStats](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/getStats): estatísticas da conexão.
|
||||
|
||||
## Arquivos
|
||||
|
||||
`sinalizacao.py`: sessões e mensagens. `painel-video.js`: receptor e fps. `transmissao.html`: captura/emissor e detector. `qualidade-auto.js`: decisão automática. MainActivity/PonteRTC: ciclo de vida, câmera exclusiva e comunicação com Java.
|
||||
@@ -0,0 +1,14 @@
|
||||
[Unit]
|
||||
Description=Cerebro local Qwen3 Carinha
|
||||
After=network.target
|
||||
|
||||
[Service]
|
||||
Environment=LD_LIBRARY_PATH=/opt/carinha-ai/llama-b11404
|
||||
ExecStart=/opt/carinha-ai/llama-b11404/llama-server -m /opt/carinha-ai/models/qwen3-0.6b-q4.gguf --host 127.0.0.1 --port 8101 -c 1024 -t 2 -np 1 --jinja --chat-template-kwargs '{"enable_thinking":false}'
|
||||
Restart=on-failure
|
||||
RestartSec=5
|
||||
Nice=10
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
[Unit]
|
||||
Description=Servidor Carinha PC no Orange Pi
|
||||
After=network.target
|
||||
|
||||
[Service]
|
||||
Type=simple
|
||||
WorkingDirectory=/opt/carinha-pc
|
||||
ExecStart=/usr/bin/python3 -u /opt/carinha-pc/kiosk-server.py --porta 8100
|
||||
Restart=on-failure
|
||||
RestartSec=3
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
@@ -0,0 +1,2 @@
|
||||
[Service]
|
||||
Environment=CARINHA_IA_URL=http://192.168.1.16:8101
|
||||
@@ -0,0 +1,2 @@
|
||||
[Service]
|
||||
Environment=CARINHA_I2C=/dev/i2c-2
|
||||
@@ -0,0 +1,18 @@
|
||||
"""Diagnóstico somente leitura; não configura PWM nem movimenta servos.
|
||||
Uso: sudo python3 verificar-pca.py /dev/i2c-N
|
||||
Confirme primeiro que N corresponde ao I2C3 do conector externo.
|
||||
"""
|
||||
import fcntl
|
||||
import os
|
||||
import sys
|
||||
|
||||
bus = sys.argv[1]
|
||||
fd = os.open(bus, os.O_RDWR)
|
||||
try:
|
||||
fcntl.ioctl(fd, 0x0703, 0x40) # I2C_SLAVE: endereço padrão PCA9685
|
||||
for name, register in [('MODE1', 0x00), ('MODE2', 0x01), ('PRE_SCALE', 0xFE)]:
|
||||
os.write(fd, bytes([register])) # seleciona apenas o registrador
|
||||
value = os.read(fd, 1)[0]
|
||||
print(f'{bus} endereço 0x40 {name}=0x{value:02x}')
|
||||
finally:
|
||||
os.close(fd)
|
||||
Reference in New Issue
Block a user