In this area you will find some proof-of-concept KESO applications that were
developed for testing various aspects of KESO.
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:
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.
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)
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.