hallo,

also das ganze klingt nach einer vernünftigen idee!
für maschinelles sehen solltet ihr aufjedenfall etwas schnelleres als einen via C7M mit 1,2GHz verwenden... (persönliche erfahrung).
ein dual-core atom mini-itx board: http://www.heise.de/preisvergleich/a356403.html
besser als I2C wäre zb CAN (gegen welchen ich mich aufgrund des geringen angebots an günstigen Sensoren entschieden habe)
ansonsten, Sensoren deren werte als schneller datenstrom in den PC sollen (beschleunigungssensor, etc) haben bei mir eine eigene MCU die (zusätzlich zum I2C slave) eine direkte rs232(usb) anbindung ermöglicht.
als programmiersprache für die MCU würde ich C vorschlagen, im falle eines atmels mit der kostenlosen kombination aus win-avr und atmel AVR studio.
dann wäre noch der pc 'zu programmieren'... und dieses kapitel wird sehr leicht unterschätzt! und dabei meine ich nicht das eigentliche programmiern (implementieren) sondern den gesamten entwicklungsprozess. es gilt sehr viele designentscheidungen zu treffen auf die wiederum andere entscheidungen aufbauen (zb protokoll(stack)). wenn man also alles selbst macht sollte man von beginn an ausgereifte protokolle verwenden. multithreading ist auch unumgänglich, mitsamt dem damit verbundenen debug-'komfort'. eine gui sollte von beginn an als seperater prozess laufen und per TCP/IP angebunden sein.
auch wenn man ein robotik framework [1] verwendet ist der aufwand nicht unerheblich, denn zuerst gilt es vorhandene produkte zu evaluieren und sondieren, und dann muss man idR trotzdem noch zumindest das protokoll zwischen PC und MCU implementieren oder gar entwickeln, und die funktionalitäten als API exponieren.
und dann fängt der spass erst so richtig an: SLAM, CV, AI,...

viel spass by viel learning by viel doing,
lg


[1] microsoft robotics developer studio, player/stage/gazebo (pyro), webots, etc