Applications


		Department of Computer Science 4



		Applications I4Copter Ring the Bell Robertino

	Dept. of Computer Science > CS 4 > Research > KESO > Applications

Proof-of-Concept Applications

In this area you will find some proof-of-concept KESO applications that were developed for testing various aspects of KESO.

I4Copter

i4copter We have ported the central flight attitude control component of the I4Copter to KESO. This component computes the thrust levels of the aircraft's four rotors from the sensor data and steering commands. Our ported component works on top of the CiAO operating system in combination with the remaining original C++ components of the I4Copter framework.

Each of the components exists in a separate KESO domain. Spatial isolation is enforced using hardware-based memory protection based on the Infineon TC1796b's memory protection unit. The component ported to KESO can optionally also be isolated using the hardware protection facilities in addition to the software-based spatial isolation provided by KESO.

Comparing the Java port and the original flight control component shows that the two variants are basically on par in terms of the required execution time. The overhead introduced by the safety features of Java (i.e., mostly the runtime checks) are compensated in other places, for example by the whole-program analysis and compile time optimizations performed by KESO's compiler jino. Details are available in the following paper:

KESO: An Open-Source Multi-JVM for Deeply Embedded Systems (JTRES 2010)

We are currently working on porting additional components of the framework to Java to analyze the overhead for application components with different application characteristics, particularly concerning the ratio of communication with other domains to internal computation.

Ring the Bell

The construction of this demonstrator is similar to the well-known Ring the bell (German: Hau den Lukas) game. The construction is composed of a plastic pipe that contains an iron projectile, 8 electric coils and 8 photosensors, each attached to one photosensor. Schematic Construction of the Demonstrator

The projectile can be elevated in the pipe by selectively activating one of the coils. Activating the lowest of the coils will start elevating the projectile. As soon as the projectile passes a coil, it must be deactivated to prevent overheating. The next in height coil can be activated to further elevate the projectile, or the projectile can be lowered by disabling all coils for a short period of time.

The electric coils can be activated and deactivated by a computer control. The photosensors report the location of the projectile to the controlling unit. Besides only elevating the projectile to the top of the pipe, there are various other possibilities for moving the projectile in the pipe:

Stepwise elevation of the projectile
Stepwise lowering of the projectile
Combinations of the above

The desired combination can be provided as a small program to the controlling unit.

The demonstrator is well suited for hard real-time purposes, as the construction requires

accurately timed controlling of the coils
reaction to triggered photosensors
- interpretation of the movement according to the program
- calculation of the next action
- accurately timed control of the next coil

A Tricore TC1796 micro controller is used to control the demonstrator. This micro controller is typically deployed in the automotive area. KESO on top of a commercial OSEK/VDX implementation is used as base for the controller application.

Technical Specifications

Distance between 2 coils: 230 mm
Height of the projectile: 82 mm
Height of a coil: 30 mm
Height of a photosensor: 54 mm (mounted on top of each coil)

Robertino

To get an overview of the Robertino robot visit openrobertino.org.

Environment

In our application the three motor controllers called micro Digital Servo Amplifier with their Atmel ATmega8535 were used to test the KESO remote method invocation on very small microcontrollers. Although the Robertino possesses a powerful industrial PC it is not used in this application and therefore disconnected from the CAN bus that connects the mDSAs.

Application

Each of the mDSAs exports a Service with methods for setting the motor speed and to query the infrared distance sensors. One of the mDSAs is an "intelligent" node (drive2) that takes control over the other mDSAs (drive0 and drive1) using their exported Service through the KESO remote method invocation. As the information from the distance sensors is very limited only a simple application could be implemented that keeps the Robertino moving straight forward until it reaches an obstacle. The Robertino then tries to avoid a collision with this obstacle by turning away from it. If there is no longer an obstacle in front of the Robertino it gets back driving straight forward.

The Service concept of KESO would allow to change program of the "intelligent" node just by changing the KESO configuration and not the application source code. It would also be possible to make another more powerful microcontroller the "intelligent" node again only by changing the configuration. This of course would require that the low level hardware drivers are available for this architecture.

Required program and data space

The required amount of program and data space for this application is shown in the following diagram.



Imprint Privacy	Last modified: 2011-01-18 13:04 MS