Per il controllo di velocità tramite encoder e PID non vedo grossi problemi con un architettura anche a 8bit. Il problema è più che altro la velocità di elaborazione o meglio, la capacità di gestire gli impulsi dagli encoder. Lo avevo già fatto con una MCU a 8 bit PIC18F (http://www.guiott.com/PID/index.html) gestendo ad interrupt i due encoder ricavati dalle rotelle dei mouse, quindi con meno risoluzione rispetto agli encoder che uso ora. Il vantaggio con il dsPIC33F è la presenza di due moduli QEI (quadrature encoder interface) che fanno già gran parte del lavoro in HW.
Ti devi fare bene i conti per i tuoi encoder, magari segui questa traccia:
http://www.guiott.com/dino/swmovimento.html
per capire se hai risorse a sufficienza, ad occhio dovresti farcela.
L'unico dubbio che ho è sulla scrittura del SW, non sono sicuro che basti usare il Wiring per realizzare una cosa del genere. Ho paura che ti debba gestire le cose a livello un po' più basso, ma è solo una sensazione, non conosco così bene gli Atmel, io avevo fatto tutto in C sul PIC, ottimizzando tutto, anche il flow del programma usando una specie di RTOS personalizzato.
Per quanto riguarda l'odometria invece serve un po' più di matematica, e una MCU a 16bit potrebbe fare la differenza.
All'epoca di Dino avevo cominciato a studiare le librerie Cordic per calcolare seni e coseni con gli interi ottimizzando al massimo i calcoli (http://www.guiott.com/dino/swdivide.html), poi ho deviato per la soluzione più facile con un PIC con core DSP che non ha grossi problemi nei calcoli anche di float.
Con un po' di applicazione non dovrebbe essere impossibile, non credo però che basti una sola scheda per controllo velocità, PID, odometria e navigazione.
ciao
P.S.
Scusate se cito così spesso pagine del mio sito, ma ci ho speso molto tempo e li ci sono tutti i miei appunti, credo possano essere utili senza che mi metto a ripetere gli stessi concetti.