-- UlucSaranli? - 24 Nov 2003

The role of RTI to act as a glue between the hardware abstraction layer of RHexLib and the CDL, PCM and the simulation execution utility functions. In doing so, it will incorporate the following pieces of functionality:

• Implementation of actuator models in translating commands from RHexLib into specific force inputs to the Arachi engine.

• Implementation of sensor models in translating state information from DE to various sensors supported by the RHexLib hardware abstraction.

• Implement the simulation "main loop", which is responsible from forward execution of DE with time intervals equal to RHexLib's update frequeny (usually 1ms).

In implementing these features, the RTI will need the following facilities to be provided by the other components in the system.

Interface to CDL:

• The ability to get handles on joints and command forces. If the joints are parametrized in different ways (tunable springs etc.), interfaces to change those parameters.

• The ability to query the local state of joints. Namely, the angular or linear position and velocities of the joint, internal forces if there are constraints of implicit spring implementations.

• The ability to get handles on various rigid bodies and query their state including position and velocity in an inertial frame or with respect to another body. It would also be useful to have access to the total force and torque on each body to implement things like accelerometers.

• The ability to access dynamic parameters and properties of objects such as mass, inertia and dimensions.

• Perhaps means of estimating "proximity", defined as the distance to the closest object in a certain range of directions. I bet we will have sensors of this sort and it would be good to start thinking about how to implement this in DE.

• Interface functions to perform forward execution of the simulation for a given amount of time.

Interface to PCM:

• The ability to detect and query recently established or broken contacts, together with associated timestamps. RTI will enforce integration at 1ms bursts, so timestamps for contact events are necessary for implementing contact sensor models.

• Means of accessing local contact state, such as relative contact configuration and velocity (for detecting slippage etc.), constraint forces associated with the contact.

• The ability to query and perhaps modulate parameters associated with a contact instance. This may be important to enable functions such as tunable compliance and damping, active claws, reconfigurable feet (based on leg angle, for example) etc.

• The ability to query the objects associated with a contact and their corresponding surface properties.

Currently, I am thinking of having two omponents to the RTI: A generic toolset and a robot specific instantiation. The toolset will provide generic interfaces for modeling actuators and sensors as well as common functions for execution flow of the simulation. The design of the toolset depends on how the interface for CDL and PCM are specified.

Possible hardware components that will need to be accessed from the hardware layer:

• DC Motors, encoders, temperature sensors, strain gauges, current sensors, voltage sensors, contact sensors, gyros, accelerometers, analog inputs, analog outputs, GPS, inclinometers, motion control unit (implemented in an MCU)?, range sensors (sonars, infrared sensors), drive controls

I think the components should be as separated as possible and possibly correspond to the actual atuators and sensors rather than things like "LegHW". This will avoid code duplication below the hardware layer as much as possible. However, it does not seem like we can design much of this until we decide what will be embedded and what will be done in the CPU.

I guess initially, I will assume the following components are available: motor commands, encoder counts, temperature sensors, voltage sensors, current sensors, gyro readings, accelerometer readings, drive controls, contact sensors.

So, once again, I favor a relatively fine granularity in the design of hardware components and shift the lumped funtionality into modules. Otherwise, it becomes hard to extend the functionality of the hardware interface without modifying existing components. It is however a tradeoff, because it makes it harder then to use the same higher level code on significantly different robots.