Treadle

Drive-by-Wire Throttle & Brake Interface Module (EZ-GO RXV Autonomous Conversion)

Interface eletrônica microcontrolada para emulação e interceptação de sinais de acelerador e freio (Drive-by-Wire) em carrinhos de golfe elétricos equipados com inversor de tração Curtis AC. O módulo traduz comandos recebidos via barramento CAN em níveis analógicos de tensão contínua exigidos pela ECU do veículo (canais Throttle e Brake), além de monitorar os pedais físicos para transferências suaves de controle (bumpless transfer) e segurança.

Projeto eletrônico: treadle.kicad_sch / treadle.kicad_pcb · BOM: treadle.csv · Datasheets: ../datasheet/

1. Visão Geral do Sistema

O módulo atua como ponte intermediária entre o computador de controle central (TI C2000 / PC Autônomo) e o controlador de motor original (Inversor Curtis AC), emulando os dois canais analógicos de comando do veículo:

                     [ Barramento CAN Veicular ]
                                 │  CAN_H / CAN_L
                                 ▼
 [ Pedal Acelerador ]──►J3─┐  ┌────────────────────────┐   ┌──────────────────┐
 (Hall 0,60–4,66 V)        ├──►│  Placa Drive-by-Wire   │◄─►│ TI C2000 /       │
 [ Pedal de Freio   ]──►J6─┘  │  Raspberry Pi Pico     │J2 │ PC Autônomo      │
 (Hall 0,60–4,66 V)           │  · CAN (GP4/GP5)       │   └──────────────────┘
                              │  · 2× MCP4725 (I2C0/1) │
                              │  · 2× AmpOp LMV358     │
                              └───────┬──────────┬─────┘
                                      │          │
                               THROTTLE_OUT   BREAK_OUT
                                  (J4)         (J5)
                                    ▼            ▼
                        [ Inversor Curtis AC — Entradas Throttle / Brake ]

Cadeia de sinal interna (por canal)

 CAN ◄──SN65HVD230◄──RP2040──I2C0──►MCP4725 #1 (0x60)──►LMV358A (Av=1,39)──R 100Ω──►THROTTLE_OUT (J4)
                        │
                        └────I2C1──►MCP4725 #2 (0x60)──►LMV358B (Av=1,39)──R 100Ω──►BREAK_OUT   (J5)

 Pedal Acelerador ──divisor 10k/18k + filtro 100nF──►ADC0 (GP26)
 Pedal de Freio   ──divisor 10k/18k + filtro 100nF──►ADC1 (GP27)

2. Especificações Técnicas

3. Mapeamento de Conectores (Bornes KRE 5,08 mm)

J1 — Alimentação / Auxiliar 5V (2 vias)

ATENÇÃO: conforme desenhado no esquemático, D1 tem anodo na barra $+5\text{ V}$ e catodo em J1-1, conduzindo da placa para fora — ou seja, J1 funciona como saída auxiliar protegida de 5 V, e não como entrada de alimentação. A alimentação da placa deve ser feita pelo conector USB do Pico ou por injeção direta de $+5\text{ V}$ na barra (VSYS). Caso a intenção seja usar J1 como entrada principal com proteção reversa, invertar a orientação de D1 antes da montagem.

J2 — Barramento CAN (3 vias)

J3 — Pedal Físico do Acelerador (3 vias)

J4 — Saída de Acelerador (2 vias)

J5 — Saída de Freio (2 vias)

J6 — Pedal Físico do Freio (3 vias)

4. Mapa de Pinos do Raspberry Pi Pico

Validado contra o netlist exportado do esquemático (kicad-cli sch export netlist):

Observações de projeto:

• Os dois MCP4725 têm o pino A0 aterrado (endereço I²C 0x60). Para evitarem colisão, cada um foi alocado em um barramento I²C distinto: canal de acelerador em I2C0 e canal de freio em I2C1.
• O barramento I2C1 (GP6/GP7) não possui resistores de pull-up externos — o firmware deve habilitar os pull-ups internos do RP2040 (~50 kΩ, suficiente para até 100 kHz) ou prever a adição de pull-ups de 4,7 kΩ em revisões futuras.
• O RP2040 não possui controlador CAN nativo: a pilha CAN deve ser implementada em software/PIO nos pinos GP4/GP5.
• O pino VBUS permanece desconectado, isolando a tensão USB do resto da placa.

5. Lista de Componentes (BOM — fiel ao treadle.csv)

6. Princípio de Operação e Equações

6.1 Estágio de ganho (LMV358, configuração não-inversora)

O MCP4725 opera com $V_{ref} = V_{DD} = 3{,}3\text{ V}$. Para atingir a excursão exigida pelo inversor Curtis (até $4{,}66\text{ V}$), cada canal usa um amplificador não-inversor com ganho definido pelos valores $R_f = 3{,}9\text{ k}\Omega$ (realimentação) e $R_g = 10\text{ k}\Omega$ (para GND):

$$A_v = 1 + \frac{R_f}{R_g} = 1 + \frac{3{,}9\text{ k}\Omega}{10\text{ k}\Omega} = 1{,}39$$

O LMV358 é alimentado diretamente na barra de $+5\text{ V}$ (e não em 3,3 V) justamente para garantir headroom de saída acima de 3,3 V.

• Repouso (0% throttle): $$V_{DAC} = 0{,}43\text{ V} \implies V_{OUT} = 0{,}43 \times 1{,}39 \approx 0{,}60\text{ V}$$
• Fundo de escala (100% throttle): $$V_{DAC} = 3{,}30\text{ V} \implies V_{OUT} = 3{,}30 \times 1{,}39 \approx 4{,}59\text{ V}$$

Nota de dimensionamento: o fundo de escala prático fica $\approx 1{,}6%$ abaixo do alvo nominal de $4{,}66\text{ V}$. Para atingi-lo exatamente, $R_f$ poderia ser ajustado para $\approx 4{,}12\text{ k}\Omega$ (série E96). Na prática, a curva de calibração do Curtis tolera essa margem.

Resolução do DAC: $LSB_{DAC} = \dfrac{3{,}3\text{ V}}{4096} = 0{,}81\text{ mV}$, resultando em passos de $\approx 1{,}12\text{ mV}$ na saída do módulo.

6.2 Condicionamento dos pedais (entrada ADC)

Cada pedal Hall ($0{,}60\text{ V}$ a $4{,}66\text{ V}$) passa por um divisor redutor seguido de filtro passa-baixa de primeira ordem:

$$k = \frac{18\text{ k}\Omega}{10\text{ k}\Omega + 18\text{ k}\Omega} = 0{,}643 \qquad f_c = \frac{1}{2\pi \cdot (10\text{k} | 18\text{k}) \cdot 100\text{nF}} \approx 248\text{ Hz}$$

O divisor garante que o sinal fique sempre dentro da faixa do ADC (0–3,3 V), com resolução equivalente a $\approx 1{,}25\text{ mV}$ por LSB referido ao conector do pedal.

7. Arquitetura de Alimentação

 USB do Pico ──► VSYS ──► [ Barra +5V ] ──┬──► U3 (V+ do AmpOp)
                                          └──► D2 ──► J3-1 (+5V_PEDAL)
                                              D6 ──► J6-1 (+5V_BREAK)
                                              D1 ──► J1-1 (+5V auxiliar)
 [ Barra +5V ] ──► VSYS ──► regulador interno ──► [ Barra +3,3V ]
                                                   ├── U1 SN65HVD230
                                                   ├── U2/U4 MCP4725 (Vref = 3,3 V)
                                                   ├── Pull-ups I2C0 (R9, R10)
                                                   ├── R7 ──► D5 (LED alimentação)
                                                   └── R5 ◄── D4 (LED status, GP16)

• Os três diodos SS14 estão orientados com anodo na barra $+5\text{ V}$, funcionando como saídas protegidas para os conectores (evitam retroalimentação da rede externa para a placa). Ver ATENÇÃO na seção 3 quanto ao papel de J1.
• A barra de 3,3 V é gerada pelo regulador do próprio Raspberry Pi Pico — nenhum regulador externo é necessário.

8. Interface CAN

Notas:

1. Como a terminação é fixa, ao integrar a placa a uma rede com outros nós terminados, medir a impedância entre CAN_H e CAN_L ($\approx 60\ \Omega$ com duas terminações) e remover R1 se necessário.
2. O RP2040 não possui periférico CAN nativo — utilizar pilha CAN baseada em PIO/software nos pinos GP4/GP5.

9. Contrato de Firmware (comportamento esperado)

10. Checklist de Montagem e Bring-up

1. Inspeção visual: orientação dos diodos SS14 (catodo = banda), polaridade dos LEDs, sentido do Pico e dos bornes.
2. Teste de potência: aplicar/alimentar 5 V e verificar a barra +3,3 V (pino 36 do Pico) e o LED D5 aceso.
3. Varredura I²C: confirmar dispositivo 0x60 em ambos os barramentos (I2C0 e I2C1).
4. Teste dos DACs: escrever meia-escala (código 2048) e conferir $\approx 1{,}65\text{ V} \times 1{,}39 \approx 2{,}29\text{ V}$ em THROTTLE_OUT e BREAK_OUT.
5. Teste dos pedais: varrer os pedais fisicamente e validar a leitura dos ADCs dentro da faixa $\approx 0{,}39$–$3{,}00\text{ V}$.
6. Rede CAN: conectar ao barramento do veículo, verificar terminação e monitorar tráfego.
7. Integração com a Curtis: com o veículo suspenso (rodas livres), validar tensões de repouso ($0{,}60\text{ V}$) antes de liberar qualquer comando de aceleração.

11. Bibliotecas Locais e Setup para Git

Este projeto não depende mais de bibliotecas instaladas globalmente (~/.config/kicad/...). Todas as libs não-padrão foram copiadas para dentro do repositório, permitindo git clone reprodutível em qualquer máquina com KiCad 7/8/9/10.

11.1 O que foi copiado e por quê

Nota "Bourns / borners": não foi localizada lib Bourns separada no sistema. O termo "bornes" refere-se aos conectores J1–J6 (seção 3). A pasta Connector_Molex atende exatamente esse papel; se no futuro houver trimpots/pots Bourns, crie libs/Bourns/ seguindo o mesmo padrão.

Tamanho: STM32F103C8T6/3dmodels/ tem ~850 MB (STEP de alta resolução). Está versionado, mas se seu remoto tiver limite (GitHub 100 MB/arquivo), use Git LFS ou limpe variantes não usadas — veja §11.4.

11.2 Estrutura após a cópia

treadle/
├── sym-lib-table          # → ${KIPRJMOD}/libs/STM32F103C8T6/STM32F103C8T6.kicad_sym
├── fp-lib-table           # → ${KIPRJMOD}/libs/STM32F103C8T6/... e ${KIPRJMOD}/libs/Connector_Molex/...
├── libs/
│   ├── STM32F103C8T6/
│   │   ├── STM32F103C8T6.kicad_sym
│   │   ├── STM32F103C8T6.pretty/
│   │   └── 3dmodels/
│   └── Connector_Molex/
│       └── Connector_Molex.pretty/
├── treadle.kicad_sch
└── treadle.kicad_pcb      # (conexões elétricas preservadas — não alterado neste setup)

Tabelas usam ${KIPRJMOD} (variável do KiCad que aponta para a pasta do .kicad_pro). Isso torna o caminho relativo ao projeto, funcionando em Windows/Linux/macOS sem edição.

Antes (quebrado fora da sua máquina):

(uri "/home/ryan/Documentos/Robsic Carrinho/libraries/STM32F103C8T6/STM32F103C8T6.kicad_sym")

Depois (portável):

(uri "${KIPRJMOD}/libs/STM32F103C8T6/STM32F103C8T6.kicad_sym")

11.3 Como usar após git clone — zero configuração

1. Requisitos: KiCad 7+ (recomendado 10.0, que gerou o projeto treadle.kicad_pro:4 versão 3).

2. git clone <URL_DO_SEU_REPO>.git
   cd treadle
   kicad treadle.kicad_pro   # ou abra pelo KiCad → File → Open Project

3. O KiCad carrega automaticamente sym-lib-table e fp-lib-table locais — não precisa instalar nada globalmente. Verifique em Preferences → Manage Symbol/Footprint Libraries → Project Specific.
4. treadle.kicad_pcb e treadle.kicad_sch abrem sem "missing library".
5. PCB não foi alterado eletricamente nesta migração, apenas as tabelas. Se vir aviso de 3D model com D:/Users/admin/... ou /home/ryan/..., é resíduo legado do footprint Blue Pill que pode ser re-atribuído depois para ${KIPRJMOD}/libs/.../3dmodels/ — não afeta fabricação.

11.4 Adicionar nova biblioteca no futuro

# Exemplo: adicionar lib Bourns de trimpots
cp -a "/caminho/para/Bourns" "libs/Bourns"
# edite sym-lib-table (símbolos) ou fp-lib-table (footprints):
# (lib (name "Bourns") (type "KiCad") (uri "${KIPRJMOD}/libs/Bourns/Bourns.kicad_sym") ...)

Dê git add libs/Bourns sym-lib-table fp-lib-table e commit.

Dica Git LFS para 3D pesado (opcional):

git lfs install
echo "libs/STM32F103C8T6/3dmodels/*.step filter=lfs diff=lfs merge=lfs -text" >> .gitattributes
echo "libs/STM32F103C8T6/3dmodels/*.wrl  filter=lfs diff=lfs merge=lfs -text" >> .gitattributes
git add .gitattributes libs/

Para repo leve sem LFS, mantenha apenas os 2 modelos usados (LQFP-48_*.step + YAAJ_BluePill_PinHeaders_No_SWD_cp.*) e apague variantes *_H_SWD, *_V_SWD, *PinSockets* (~750 MB).

11.5 Primeiro git push (se ainda não é repo)

cd treadle
git init
git add sym-lib-table fp-lib-table libs/ treadle.kicad_sch treadle.kicad_pcb treadle.kicad_pro README.md treadle.csv
git status   # confirme que não há caminhos absolutos: grep -r "/home/ryan" -- . deve retornar vazio
git commit -m "feat: torna libs STM32 e Molex (bornes) locais e portáveis via \${KIPRJMOD}"
git branch -M main
git remote add origin <URL>
git push -u origin main

.gitignore já ignora *.lck, *~, treadle-backups/ e *.bak* — pastas de backup do KiCad não vão para o remoto.

11.6 Checklist de portabilidade

• grep -r "D:/" treadle/ só retorna resíduos opcionais de 3D (não crítico)
• grep -r "/home/ryan" treadle/ vazio para sym-lib-table/fp-lib-table
• Abrir esquemático → ERC 0 erros de lib
• Abrir PCB → DRC sem "missing footprint"