HRIM component model

As in mentioned in general structure section, HRIM is composed by of all the components that are standardized. Each one is represented by its own HRIM component model, for example: HRIM RotaryServo model, HRIM Camera model and so on.

This section explains in detail what each HRIM component model is composed, in order to complement the general structure section and make more understable each standadized module.

Each HRIM component model will be summarized through the following template, which is divided in two main categories: the first category includes the topics, services, actions and the second, the parameters, all of them labeled with mandatory (M) or optional (O). Furthermore, the color code used in the figure of the general structure section has been respected.

HRIM component model: <DeviceName>
id ID.msg topic (Sub) M Component identification.
status Status.msg topic (Sub) M How the module is working.
power Power.msg topic (Sub) M Describes the power supply type and give the information about the module power consumption.
specs_comm SpecsCommunication.msg topic (Sub) M Describes the communication aspects of the component.
state_comm StateCommunication.msg topic (Sub) M Published the resources that the component is using at the moment
module_3d Simulation3D.msg topic (Sub) M Ask for the 3D model of the HRIM component.
module_urdf SimulationURDF.msg topic (Sub) M Ask for the information of, 3D model of the HRIM component.
specs Specs<DeviceName>.msg topic (Sub) M Device features. <Each device described by the DeviceName has a customize message.>
<device_purpose> <DevicePurpose>.msg/.srv/.action topic/service/action
(Pub/Sub)
M <Control the essence of the device.>
Minimum amount:1
<additional_capability> <AdditionalCapability>.msg/.srv/.action topic/service/action
(Pub/Sub)
O <Additional characteristics that the device can contain related to the objective.>
Minimum amount: 0
<optional_hardware> <OptionalHardware>.msg/.srv/.action topic/service/action
(Pub/Sub)
O <Extra characteristics given by integrated hardware that by itself has no relation with the principle device.>
Minimum amount: 0
Parameters
<parameter_name> <data_type> <unit> M/O <description>

where:

HRIM component model: <DeviceName>
<topic_name>
<service_name>
<action_name>
<message_name>.msg
<service_name>.srv
<action_name>.action
topic/service/action
(Published (Pub) / Subscribed (Sub))
Mandatory (M) / Optional (O) <descriptionl>
Parameters
<parameter_name> <data_type> <unit> Mandatory (M) / Optional (O) <description>

The first five topics listed in the HRIM component model, are the common topics that use generic messages. The next items discuss the general concept of the common topics with the proposed messages:

hrim_generic_msgs/msg/ID.msg is the identification of each module. It is designed to inform the user and also the system about the component itself. /id topic should be programmed to be released only when the user requires it.

std_msgs/Header header

uint8 HRIM_COMM=0
uint8 HRIM_SENSOR=1
uint8 HRIM_ACTUATOR=2
uint8 HRIM_COGNITION=3
uint8 HRIM_UI=4
uint8 HRIM_POWER=5
uint8 HRIM_COMPOSITE=6
unit8 device_kind_id     # device classification

string device_name       # sub-type, for example, camera
uint32 vendor_id         # identifier to identify the vendor
unit32 product_id        # part-number
unit32 instance_id       # unique number to identify the module

string hrim_version      # used hrim version
string hros_version      # used h-ros version

hrim_generic_msgs/msg/Power.msg publishes information of the power source, and the current power consumption. The Power.msg provides continuous information regarding the power consummation and power requirements of each module, allowing the easy construction of modular robots.

std_msgs/Header header

float32 voltage
float32 current_consumption
float32 current_surplus          # curret injection for the whole system
float32 power_consumption
float32 power_surplus            # power injection for the whole system

hrim_generic_msgs/msg/Status.msg is designed to inform about the resources that are being used by each component. Similar to the Power.msg, it is programmed to publish continuously in order to simplify the robot building process.

std_msgs/Header header

uint32 instance_id      

# CPU
float32 system_cpu                        # Total CPU utilization in %
float32 core_temperature                # CPU temperature in C

# RAM
uint32 system_ram_total                 # Total RAM in MB (megabyte)
uint32 system_ram_used                  # Used RAM in MB (megabyte)
uint32 system_ram_free                  # Free RAM in MB (megabyte)

# Disk I/O
float32 system_io_in                      # Disk I/O IN in kilobytes/s
float32 system_io_out                     # Disk I/O OUT in kilobytes/s

# IPv4 Bandwidth
string[] system_ipv4_ip                 # IP address (xxx.xxx.xxx.xxx/zz) *
float32 system_ipv4_received            # IPv4 bandwidth received in kilobits/s
float32 system_ipv4_sent                  # IPv4 bandwidth sent in kilobits/s

# IPv4
uint16 ipv4_tcpsock                       # Number of TCP active connections
float32 ipv4_tcppackets_received        # Number of TCP received packets
float32 ipv4_tcppackets_sent              # Number of TCP sent packets
float32 ipv4_tcp_errors                   # Number of TCP error packages
float32 ipv4_udppackets_received        # Number of UDP packets received
float32 ipv4_udppackets_sent              # Number of UDP packets sent
float32 ipv4_udp_errors                   # Number of UDP error packages

float32 cpu_interrupts
float32 cpu_context_switches

uint32 softnet_processed
uint32 softnet_dropped
uint32 softnet_squeezed
uint32 softnet_received_rps
uint32 softnet_flow_limit_count
uint64 softirqs_hi
uint64 softirqs_timer
uint64 softirqs_net_tx
uint64 softirqs_net_rx
uint64 softirqs_block
uint64 softirqs_irq_poll
uint64 softirqs_tasklet
uint64 softirqs_sched
uint64 softirqs_hrtimer
uint64 softirqs_rcu

float32 load1
float32 load5
float32 load15

hrim_generic_msgs/msg/SpecsCommunication.msg and hrim_generic_msgs/msg/StateCommunication.msgallow the user to obtain information about the communication aspects of each component.

hrim_generic_msgs/msg/SpecsCommunication.msg published the capabilities in term of communicaction that the component offers.

std_msgs/Header header

double min_comm_rate          # the minimum frequency at which the component can work (Hz)
double max_comm_rate          # the maximum frequency at which the component can work (Hz)

double max_size_msgs          # the maximum amount of megabits that the component will send (Mb)

hrim_generic_msgs/msg/StateCommunication.msg published the resources that the component is using at the moment.

std_msgs/Header header

double comm_rate             # the frequency at which the component is working (Hz)
double size_msgs             # the  megabits that the component in sending (Mb)

hrim_generic_msgs/msg/Simulation3D.msgand hrim_generic_msgs/msg/SimulationURDF.msg allow the user to obtain the 3D model and a URDF fragment of each module in order to build a virtual robot which then can be easily used in simulation frameworks, such as Gazebo or MoveIt. The simulation topics do not start publishing until they detect a user interface or a simulation framework connected to the system.

std_msgs/Header header

byte[] 3d_model         # .stl of the component
std_msgs/Header header

string urdf_model       # the urdf corresponding to the .stl

The rest of the HRIM component model abstractions, such as specs or device purpose, are specifically designed and customized for each component. To give a better understanding of these concepts, a practical example is given by one of the most used module: HRIM rotary servomotor model.

You can also enter directly into any of standardized component, however, unlike the example they are not detailed step by step.