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.
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.>|
|M||<Control the essence of the device.>
|O||<Additional characteristics that the device can contain related to the objective.>
Minimum amount: 0
|O||<Extra characteristics given by integrated hardware that by itself has no relation with the principle device.>
Minimum amount: 0
|HRIM component model: <DeviceName>|
(Published (Pub) / Subscribed (Sub))
|Mandatory (M) / Optional (O)||<descriptionl>|
|<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/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/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.