As you may have heard by now, CEBot is the “Core Project” used in Socrates and currently requires the use of two different boards from ICOP Technologies and EMAC, Inc. So what will the engineering student do if they can’t afford to purchase these boards, a distinct possibility if I remember my own days as a student? This is where Rossum comes in.
My plan is to produce an extension module for the Windows CE emulator to allow the simulated sensor output from Rossum to be directed to the CEBot device driver modules running in the emulator. Though the hardware level interface presented to the device drivers will be quite different when running in the emulator (through a simulated DMA channel in the CE emulator), it will allow a significant percentage of the same code to be run, and enable experimentation with different navigation algorithms.
So how would this look when it is all up and running? The developer defines and builds a CE kernel and targets the emulator. The emulator window appears when the build process is complete and the kernel image is loaded and run in a virtualized PC. The developer then loads the Rossum graphical shell, causing the Rossum engine to begin listening on its specified port for a connection. The developer then executes a robot navigation application in the CE emulator, causing various device drivers to be loaded and initialized. This, in turn, causes the emulator CEBot extension to automatically form a network connection with Rossum allowing it to receive sensor data and send actuator commands.
The navigation algorithm running in the emulator then commands the robot motors to begin rotating in a designated direction and velocity, calling the appropriate device driver function. This causes the motor controller hardware to be accessed and causes the CE emulator extension to begin receiving certain data (through the emulator’s DMA channel) from the device driver. The emulator extension then translates this data to Rossum commands which are sent over the designated Rossum network port, resulting in the motion of the simulated robot in the Rossum graphical shell.
It would require a good bit of effort to get this working, but if successful would allow device driver development with simulated robot hardware (through the use of the CE emulator), operating in a simulated robot environment (through the use of Rossum).
Would this be useful to embedded system engineering student? It allows the student without physical hardware to experiment with CE driver development using an interesting and entertaining simulated robot. What is lacking, however, is all the other challenging aspects of embedded systems development that emerge when physical hardware is present, such as platform initialization, remote debugging, kernel image upload to a target platform, and most importantly, dealing with I/O from physical hardware.
Please let me know what you think.