An optical instrument that provices a 3D reading about the environment. I differentiate three types: Depth sensor, Stereo camera and ToF camera. As they have been categorized according the hardware each one as to have its own Specs<device_name>.msg.

Create:

• SpecsDepthSensor.msg

• SpecsStereoCamera.msg

• SpecsToFCamera.msg

Inside UI we have already RC.msg.

• Include RC.msg in the documentation.

DC motors are among the most common type of motors used.

Obj: Design the HRIM DC motors model.

Steps:

• Market analysis, devices and datasheets.

• DC motors main purpose.

• Mandatory topics, messges and so on.

• Optional topics, messges and so on.

• Github

• Docs

Describe the feature that you would like to include:
Update travis to latest ROS2 version

Additional context
NONE

Torque sensors messages have to be modified:

• Specs: rightnow it doesn´t report enough information. For example, axes amount, precision or security factor.
• Torque: Units? the torque has to be reported in Nm
  @ibaiape we will work together on this.

Describe the feature that you would like to include:
I would like to have a hrim command line tool. I will start working on it and I'll create a PR to be verified.

Additional context
NONE

Improve the Robotics Arm Model (Composite - Arm):

• Add joint_name to RotaryServomotors.

• Add JointStatus.msg to Arm.

• Add MoveCommand.srv to Arm.

• Add TrayectoyCommand.srv to Arm.

• Add RobotStatus.msg to Arm.

I propose to change the name of error for the topic state for servos:
https://github.com/AcutronicRobotics/HRIM/blob/master/models/actuator/servo/topics/state.xml#L14

Using the name error for the following error could lead to confusions. For example error could be referring also to error codes or fault states. I think it would be more descriptive to use following_error directly.

Broken links and missing files from docs

ie https://acutronicrobotics.com/docs/technology/hrim/model/implementations/actuator/rotary%20servomotor

has a link like

https://github.com/erlerobot/HRIM/blob/master/actuator/RotaryServo/hrim_actuator_rotaryservo_msgs/msg/GoalRotaryServo.msg

IE 404 error

Any links to the former blob directory path and beyond from your website doc links now breaks all your links from your website to the support file links and you have lots links that have 404 page errors

you might want to fix that as it makes it hard to follow along

Describe the bug
When compiling HRIM I get following error in hrim_qa package:

Starting >>> hrim_qa
--- stderr: hrim_qa                           
CMake Error at CMakeLists.txt:29 (SUBDIRLIST):
  SUBDIRLIST Macro invoked with incorrect arguments for macro named:
  SUBDIRLIST


---
Failed   <<< hrim_qa	[ Exited with code 1 ]

To Reproduce

• Follow ROS2 installation instructions from sources (Dashing)
• Clone HRIM repo in src folder and generate the models
• colcon build --symlink-install --merge-install

Expected behavior

• I expected to compile whole ws without errors

I am curious how to best use HRIM for something like multiple axis linear actuators. For example, three linear actuators may be stacked on top of each other to construct an XYZ stage. Each linear actuator may be driven in a variety of ways, perhaps by a stepper motor, or a servo motor with an encoder, or a linear motor with an encoder. There may be two limit switches and a home switch for every axis. Each axis may be driven in either position mode, accelerating and decelerating to a target position, or in a velocity mode, where it just accelerates to a target velocity until it receives a new command. Target positions may be absolute with respect to the home switch or relative with respect to the current position. The number of axes might be variable. Would you consider a linear actuator a composite device or a basic actuator type or is that an example of an electric motor actuator? Is there a way to translate units to account for gearboxes or rotary to linear mechanisms or microstep counts?

Hi,
I have downloaded the MARA simulation and HRIM generated packages for messages.

I can see that in the generated directory, there are all the message packages required to make MARA run using the HRIM interface (generic, geometry, gripper, rotaryservo). However, if I have correctly understood, those packages have been generated by compiling the XML files that define the MARA interfaces, using the command:
python3 hrim.py generate <some_xml_file>

Where can I get those XML files? They will be very useful for me in order to better understand how to create my own.

After the last update of HRIM some dependencies required by MARA have disappeared, making MARA unusable.

hrim_generic_msgs
hrim_actuator_rotaryservo_msgs

I will try to take a look at the new HRIM and update MARA. In the meantime, it would be a good idea to create a temporary branch (mara) with the previous version of HRIM.

To include communication we will have to create a new generic msg (all the components have to include).

Describe the feature that you would like to include:

This is an open discussion on order to extend HRIM error management.

Additional context

Currently errors in HRIM are just a subfield on certain topics. There is not a common way to deal with errors for all the components. For instance, in the case of HRIM/models/actuator/servo/topics/state.xml the error are specified in field called fault with the following faults:

• "FAULT_NONE": 0
• "FAULT_CURRENT": 1
• "FAULT_TEMPERATURE": 2
• "FAULT_BUS_VOLTAGE": 3
• "FAULT_BRIDGE_DRIVER": 4

It would be good to have a common definition of error that can be shared by all modules. In this way, error management could be consistent for different types of modules. The error semantic would be different for each component, but not the structure. That means that I can call the same function in order to retrieve the error for an actuator or a gripper.

I propose to follow a structure similar to the one used in CMM machine standard language (I++ DME (Dimensional Measurement Equipment) | NIST) (chapter 8 Error Handling):

In this implementation the error is composed by:

• A severity code (F1)
• A code defined inside the standard (F2). This could be an error defined in HRIM.
• Native error code (F3). An error code which is provided each component vendor. i.e: 0x0080 (Position following error).
• A string describing the error.

Apart from the message structure we would need to define an error classification for each component type. Some error codes could be common for all modules (i.e: communications failure, generic, wrong parameter, etc..) and other specific for each module type.

@ibaiape, @ahcorde, we spoke a while ago about the need to make another release of HRIM.

Once you finish with all the existing work we're doing, could we please make a new release, document it at https://acutronicrobotics.com/docs/technology/hrim and spread the word a bit?

Describe the feature that you would like to include:

I would like to include an acceleration field in StateRotaryServo. Something like this:

 <property name="acceleration" type="float64" unit="radians per second squared" description="current acceleration ">

Hi,

This is a thread to share and discuss together our experiment and vision about modular tools for roboticists as planned with @vmayoral.

Who am I ?

I'm CEO at Luos robotics: www.luos-robotics.com
At Luos we create modular tools for roboticists and we target mass produced robots. We recently discovered your amazing work, and our solution is REALLY close to HRIM (and HROS I guess).
We are aware of open-source (we once created this project: https://www.poppy-project.org) but unfortunately we don't use it a lot for now at Luos.

What are the big chalenges that modular robots will have to face?

I think we have a common interest of enabling modular robots market.
From our point of view, biggest challenges are:

• Education: We have to make developers aware of our way of thinking. To do that, we have to explain the differences and benefits with the traditional way, and we have to make easy-to-use and easy-to-understand documentation.
• Price: Modular technologies are absolutely great for prototyping because they save a lot of time and make it reachable for less technical persons, but it's expensive. To keep it on the final product, we have to reduce the cost of the hardware needed for modulrarity.

About HRIM

We love the HRIM initiative, we planed to do something similar by ourselves, but it's better if the movement is already existing. It could be a good start to create something that everyone can use and benefit to.
We would like to brainstorm with you about it because having different points of view could make HRIM the obvious way for robots and I think we could be HRIM-compatible.
I am not really familiar with this kind of brainstorm on Github Issue (usually we use our forum to do it) but I can deal with it ;)

About us

We have something pretty similar to HRIM running on our products and we have customers that use it every day. We transmit and share our "HRIM like" data between modules using RS485 and a daisy chain link allowing us to detect topology of the network. The protocol and the physical way to transmit is called Robus. We can run Robus on any microcontrolers; at the begining we used 8bit microcontrolers. Now we have a "mother board" called L0 (Quite similar to your SoM) with an ARM cortexM0 on it.
To link the network to a computer we use communication modules as gateways. These modules transform our "HRIM like" data into JSON and reverse.

Currently, our users only deal with JSON on the computer side (some of them use it with ROS).
More information is available on our doc: https://www.luos-robotics.com/en/documentation/general-use/

Obj: Design the HRIM GPS model.

Steps:

• Device analysis, Global Positioning System (GPS) : a receiver that calculates geographical location by satellites.

• GPS main purpose.

• Market analysis.

• Design the topics, messges and so on, with the interoperability in mind.

• Github

• Docs