Open gavanderhoorn opened 1 year ago
Some quick thoughts on a possible design.
GetActiveAlarmInfo.srv
:
This service returns two lists with instances of AlarmInfo
, one instance per active alarm and/or error.
I've deliberately made errors
a list, even though there can only be one active error at any specific time (AFAIK). Reason is it would otherwise be difficult to communicate "no active error" (it would require setting all fields of the singular instance of AlarmInfo
to 0
or ""
, which is doable, but not as nice as just not having an AlarmInfo
instance in the first place).
With errors
being a list, it's just a simple check for len(errors) == 0
-> no active errors.
Same for alarms
.
re: CauseRemedyPair.msg
: I'm not sure we should include this. I'm not happy about the name, and I believe at some point we could require users to lookup information about alarms & errors in the available (off-line) documentation.
re: AlarmInfo.msg
: all these string
fields will make handling memory and message initialisation somewhat more complex than just a couple of primitives, but it's probably worth it.
@ted-miller: would you have any recommendations as to which M+ APIs to use to retrieve the data we'd need for this service?
Unfortunately, there aren't any public API's available for retrieving the alarm message
. We may be able to obfuscate something in the platform lib. But I'm hesitant because even I don't have any documentation on that functionality. Additionally, the approach I'm considering would not work on DX2/FS.
There is no API at all for getting the cause-remedy
info.
There is a possible alternate approach. The alarm message
and also the cause-remedy
info are both stored in a csv file on the standard pendant. We could potentially open an FTP connection to the pendant and fetch that file. However, the Smart Pendant uses an encrypted FTP connection (I have no idea how that works).
Something else to consider is the fact that none of the MotoROS2 alarms have cause-remedy
info stored on the controller.
Skeleton: main...gavanderhoorn:motoros2:get_active_alarm_info.
it's slightly less skeleton-y now.
Needs an updated M+ libmicroros
with the GetActiveAlarmInfo
service definition. We have a build artefact available in the libmicroros
builder in case you're interested @ted-miller.
Edit: btw, the cause/remedy parts are commented at the moment.
Unfortunately, there aren't any public API's available for retrieving the alarm
message
. We may be able to obfuscate something in the platform lib. But I'm hesitant because even I don't have any documentation on that functionality. Additionally, the approach I'm considering would not work on DX2/FS.
hm.
I'll take a look a later to see whether I can find something for those latter two.
There is no API at all for getting the
cause-remedy
info.
Other than reading the .csv
s you mention below, right?
There is a possible alternate approach. The alarm
message
and also thecause-remedy
info are both stored in a csv file on the standard pendant. We could potentially open an FTP connection to the pendant and fetch that file. However, the Smart Pendant uses an encrypted FTP connection (I have no idea how that works).
I don't believe there's support for that (ie: SFTP) in M+ (or anything below that).
The .csv
s are already on the controller's file system, are they not?
Something else to consider is the fact that none of the MotoROS2 alarms have
cause-remedy
info stored on the controller.
well, that's somebody-else's problem ;)
There is no API at all for getting the cause-remedy info.
Other than reading the .csvs you mention below, right?
Yeah. I don't consider parsing a csv to be an official "api".
I don't believe there's support for that (ie: SFTP) in M+ (or anything below that)
No. I've implemented regular FTP in M+ before. But not SFTP.
The .csvs are already on the controller's file system, are they not?
Very bad things happen when you touch that file system. I will not access that SD card.
After some deliberation and thinking about it more, my new proposal would be as follows (I've removed some of the comments to reduce verbosity):
I'd like to make progress and implement just the minimal <code, name, sub_code>
-returning version of the service.
That would allow users access to error/alarm information while we can take some time to figure out how to implement the additional functionality (ie: retrieve more detailed error/alarm descriptions and information about possible causes and remedies).
The contents
, description
and help
fields would just be empty/not set in the initial implementation.
Note: I've removed the notes
field from AlarmCauseRemedy
as I don't believe it adds a lot of value.
In the .csv
s I've checked, it seems to contain an identifier for a 'category' or 'subsystem' responsible for raising the alarm.
This could be valuable information, but some of the .csv
s appear to have Japanese text in that column for some rows, which would complicate storing it in a ROS msg (it's possible though would need a different field type).
@ted-miller: if you agree with this proposal, I'll update Yaskawa-Global/motoros2_interfaces#9 and start on finalising the discussed functionality.
Something else to consider: I find the name of the name
field rather confusing. The .csv
s call it "Alarm Name/Message" and the latter seems more logical to me.
I always have to remember that "name == message".
I find the root.message
to be unintuitive. My first thought is that this should be the alarm message. I get why it's there... just maybe rename it to serviceresult
or something similar-ish.
I always have to remember that "name == message"
I would suggest renaming the name
field to message
.
reserved for future use: contents (from CSV) reserved for future use: meaning (from CSV)
I've never had a clear understanding of the distinction between these fields. I'd suggest combining into one. We can just concat the contents of the csv file.
motoros2_interfaces/AlarmInfo[] errors identical to 'alarms' field above
There is no csv file for error information. I think these should just be a number and message. (I'm not sure whether errors have subcodes.)
I find the
root.message
to be unintuitive. My first thought is that this should be the alarm message. I get why it's there... just maybe rename it toserviceresult
or something similar-ish.
yeah, so the thing is we have this pair of fields (result_code
, message
) in some of our other service definitions (all our IO services fi). I'd like to see whether we can keep things consistent across different services.
I'd be OK with result_message
(as the complement of result_code
).
But then I'd also like to rename the field in other definitions.
I always have to remember that "name == message"
I would suggest renaming the
name
field tomessage
.
:+1:
reserved for future use: contents (from CSV) reserved for future use: meaning (from CSV)
I've never had a clear understanding of the distinction between these fields. I'd suggest combining into one. We can just concat the contents of the csv file.
hm. Ok. I'll take a look whether that works in general. There's quite some variation in those .csv
s.
motoros2_interfaces/AlarmInfo[] errors identical to 'alarms' field above
There is no csv file for error information. I think these should just be a number and message.
I liked being able to reuse the same AlarmInfo
struct for both.
I'll prototype an ErrorInfo
type.
I'm not sure whether errors have subcodes.
the internal API definitely suggests they do.
@ted-miller: I've updated the message definitions in https://github.com/Yaskawa-Global/motoros2_interfaces/pull/9.
Only thing I haven't done I realise now is:
reserved for future use: contents (from CSV) reserved for future use: meaning (from CSV)
I've never had a clear understanding of the distinction between these fields. I'd suggest combining into one. We can just concat the contents of the csv file.
We could still decide to do that.
I'll take a look at the .csv
s to see whether it would indeed make sense / work.
I've never had a clear understanding of the distinction between these fields. I'd suggest combining into one. We can just concat the contents of the csv file.
Ignore that comment. I was thinking of something else.
They should be separate.
Implement a service (perhaps
motoros2_interfaces/GetActiveAlarmInfo
or similarly named) which clients could invoke to retrieve more information about active alarms/errors.We could expose other data next to alarm subcode data. If available, we could perhaps have it return string descriptions of alarms & errors and other information (possible remedies?).
We can't add this to our
RobotStatus
publications, as that message doesn't have the necessary fields (and they can't be added either, as it should stay generic / vendor-neutral).Edit: note that this service is not intended to be a replacement of
RobotStatus
. Retrieving the information returned by the service incurs overhead, and should really only be used to get more insight into alarms/errors reported viaRobotStatus
publications.