Service and message definitions for reading and writing variables #24
Conversation
Use var_number, in the request section, instead of address as MotoPlus uses the term var_no in their documentation.
Use var_number, in the request section, instead of address as MotoPlus uses the term var_no in their documentation.
Use var_number, in the request section, instead of address as MotoPlus uses the term var_no in their documentation.
Use var_number, in the request section, instead of address as MotoPlus uses the term var_no in their documentation.
Use var_number, in the request section, instead of address as MotoPlus uses the term var_no in their documentation.
Use var_number, in the request section, instead of address as MotoPlus uses the term var_no in their documentation.
Use var_number, in the request section, instead of address as MotoPlus uses the term var_no in their documentation.
Use var_number, in the request section, instead of address as MotoPlus uses the term var_no in their documentation.
Use var_number, in the request section, instead of address as MotoPlus uses the term var_no in their documentation.
Use var_number, in the request section, instead of address as MotoPlus uses the term var_no in their documentation.
Use var_number, in the request section, instead of address as MotoPlus uses the term var_no in their documentation.
Use var_number, in the request section, instead of address as MotoPlus uses the term var_no in their documentation.
…aces can be build.
could I suggest The former matches the M+ API spec even closer: typedef struct
{
USHORT usType;
USHORT usIndex;
} MP_VAR_INFO;and is also less ambiguous ('number' could also mean 'amount'). |
|
I am using the M+ function typedef struct
{
int var_type;
int var_no;
union {
MP_B_VAR_BUFF b;
MP_I_VAR_BUFF i;
MP_D_VAR_BUFF d;
MP_R_VAR_BUFF r;
MP_S_VAR_BUFF s;
MP_P_VAR_BUFF p;
MP_P_VAR_BUFF bp;
MP_P_VAR_BUFF ex;
} val;
} MP_USR_VAR_INFO;Here they use Would be |
|
I know the manual states it's much faster, but I'm wondering if that is even noticeable compared to the ROS 2 service overhead. Even with this in mind, I might still suggest using |
|
Personally, I'd suggest actually using |
|
High-level comment: would we want to 'condense' things a bit? By which I mean: instead of having separate services for reading and writing bytes and ints, we could just have one, which truncates whatever comes in if it's writing to a byte variable. Same for floats (reals) and doubles. I'm not a fan of union message definitions, so that's not what I'm suggesting, but right now we'd be adding 12 services to MotoROS2. The alternative (after combining a few) would save us 4 service servers. This would be different from the IO ROS API though, where we didn't do this, but I wanted to put it up for discussion at least. |
In this case, IMO, they should all be separate services. But I don't feel strongly either way. My only concern is whether the extra services impacts performance of the executor that monitors them. |
ah, right. I confused it with double precision floating point.
should not matter too much. Either we add a new executor, or we add it all to the IO executor. I don't expect performance issues, as long as clients don't start calling these services at high frequencies. Which is not what services are for. It's just another 14 entries in the |
In the MR2 implementation that I have started, I have already added a new executor.
I agree on that. |
yes, I saw (Yaskawa-Global/motoros2@3e66e15). But we should avoid starting another task for it. That should not be needed. Just add it to the task that's spinning the IO executor. |
|
Another question would be whether we really need to expose all variables types? |
my initial response would indeed be: yes, we should offer all of them. Can you motivate why we could leave out int and double? That would make it impossible to write numbers larger than 255 to variables and make the |
|
I saw it more from the application side, how I would use the services.
But this would be only a thing if we want to reduce the amount of services, as we mentioned earlier. |
…and write negative values as well.
There was a problem hiding this comment.
[External email]: I have a question regarding transforming the Pose from Ros to Yaskawa base frame.
I've got some conversion examples in
This function specifically converts from a Yaskawa cartesian position to a Transform
(I'm not sure if this answers your original question or not
|
So, how should we implement this now? We also need to make a decision regarding naming the variable number |
I think we should allow access to all variable types (BIDRSPBpEx).
I vote for |
|
Okay, then lets take ´address´. So until now I have allowed access to the variable types (BIDRS) and for P I need to implement it. But here the question remains regarding the position representation. After finishing this implementation I would implement Bp and Ex in a step two. |
But I do think it makes sense to allow for additional formats. So perhaps a struct of: Though I'm not sure how you indicate which of these struct members are 'valid'. But perhaps that's up the developer of the end-application? |
|
okay that sounds good! |
|
@yeu-geissdoerfer: friendly ping? |
|
@gavanderhoorn Unfortunately I don't have time to finish the implementation at the moment. |
Added service definitions for reading and writing each variable type. A message definition for the error codes has also been added.
Each service definition has "var_number" as the variable name in the request section, as this wording fits better with the MotoPlus function definition used, than using the name "address".
For reading and writing position variables, the service has been kept as proposed. The positions are in the ROS-Industrial base frame. A corresponding motoros2 function will convert this ROS-Industrial base frame position to a Yaskawa base frame position and vice versa, since the robot controller it self cannot deal with the ROS-Industrial base frame directly. If needed, the option to define positions in the tool or user frame can be added in a later version.