bei Robotern hat man immer wieder das Problem, dass irgendwelche notwendigen Pausen für Events bei anderen Events stören, wenn Ereignisse quasi-simultan registriert und bearbeitet werden müssen. Das gilt ntl auch für andere Datenverarbeitungsprobleme. Daher ist mE Multithreading per time-slice-scheduling sowieso unumgänglich, was ja auch der Grund dafür ist, dass MT von den allermeisten Programmiersprchen (besonders auch für Roboter-Plattformen) unterstützt wird (gcc C POSIX pthread, C++ std::thread, Java, C#, sogar Lego NXT-G und EV3-G (alle pre-emptiv) und Fischertechnik RoboPro (kooperativ). Tatsächlich nutzt MT bei Arduino nur bestimmte Interrupts sehr geschickt, um Daten, Datenregister und Speicherbereiche zu sichern und wiederherzustellen, was man auch bare-metal tun kann, aber MT libs machen das eben sehr elegant und user-freundlich per high-level-API-Funktionen, die auch zusätzlich sehr "failsafe" programmiert und getestet sind.

Von daher würde ich mich eher um Multithreading kümmern, wie ich es oben verlinkt habe, dann klappt es auch mit diesen und anderen blockierenden Funktionen.
Auch wenn die Scheduler Lib bereits für Nano und Uno geeignet sind, würde ich dennoch eher einen Mega empfehlen als MCU, besser noch einen SAMD oder SAM (Arduino Zero/M0, Due, Teensy).
Robotik ist nun mal etwas anspruchsvoller als simple Katzenklappensteuerungen, und z.B. auch Lego- oder FT "bricks" besitzen ja keine AVRs sondern ARM Prozessoren, aus gutem Grund.
Aber wie erwähnt, der Scheduler funktioniert dennoch auch bei kleinen AVRs.