Robotics middleware: Difference between revisions

Revision as of 10:45, 6 February 2009

Revision as of 13:03, 6 February 2009

Line 29:

* [[Simulink]] blocks in feedback controllers: one often has to introduce explicit delay blocks; one cannot predict the overall performance on the basis of the performance of the individual blocks.

* [[Real-time computing|Realtime]] aspects at the system level: only one of the components can really have the highest priority; schedulability of the activities in all components becomes exponentially harder to analyse, let alone to guarantee, when the number of components grows; [[Inter-process communication|IPC]] [[deadlock]]s become more likely, and more difficult to trace; [[formal verification]] becomes more difficult, since [[jitter]] and [[latency (engineering)|latency]] deteriorate in less predictable ways, compromising the ideal, abstract model of states with atomic and infinitely fast transitions and condition checks.

* Adding sensorssensor processing or control blocks to a control loop: each new sensor can bring with it a [[device driver]] that requires a different [[sampling frequency]], that provides a different [[spatial resolution]], …

==Robotics middleware projects==