Output by writeDigitalOutput differs from readDigitalOutput input values

[130s]

UPDATE 20170803: We got an updated proprietary library from the manufacturer. We'll plan to test it on a real robot, but probably within a month range.

If any of the users are in need of this, please contact either on this ticket, or via TORK support.

---

A user who owns a robot since Augst, 2014 is experiencing this.

Compare the last bit (31th) in the following example.

In [1]: b=robot.readDigitalOutput()

In [2]: b
Out[2]: 
[1,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0]

In [3]: b[31]=1

In [4]: robot.writeDigitalOutput(b)
Out[4]: True

In [5]: robot.readDigitalOutput()
Out[5]: 
[1,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0]

In [6]: 

[7675t]

I followed the codes from upper level to lower, and couldn't find problem.
I guess the lowest level function read_digital_output in NXO library may have something.

Related Issue
fkanehiro/hrpsys-base#85

Related commit
fkanehiro/hrpsys-base@525ac45

[antgarmun]

Hello, I am triying to use both: writeDigitalOutput() and readDigitalOutput(), but It doesn't work. I have the next output information:

In [2]: b=robot.readDigitalOutput()
BAD_OPERATION                             Traceback (most recent call last)
/home/kwduser/<ipython-input-2-4ab7a4ba7bdd> in <module>()
----> 1 b=robot.readDigitalOutput()

/opt/ros/hydro/lib/python2.7/dist-packages/hrpsys/hrpsys_config.pyc in readDigitalOutput(self)
   1554         @return list of int: List of the values in digital input register. Range: 0 or 1.
   1555         '''
-> 1556         ret, dout = self.rh_svc.readDigitalOutput()
   1557         retList = []
   1558         for item in dout:

/opt/ros/hydro/lib/python2.7/dist-packages/hrpsys/RobotHardwareService_idl.pyc in readDigitalOutput(self, *args)
    273
    274     def readDigitalOutput(self, *args):
--> 275         return _omnipy.invoke(self, "readDigitalOutput", _0_OpenHRP.RobotHardwareService._d_readDigitalOutput, args)
    276
    277     def getStatus2(self, *args):

BAD_OPERATION: CORBA.BAD_OPERATION(omniORB.BAD_OPERATION_UnRecognisedOperationName, CORBA.COMPLETED_NO)

[130s]

@antgarmun the error you're seeing #340 (comment) seems irrelevant despite that you're using the same method. Opened as a separate ticket #343

[130s]

Following #340 (comment), I do not find anything relevant to this issue on opensource land (incl. hrpsys, libhrpiob) either. I asked a robot owner (with hrpsys 315.1.8, dio_version 0.4.2) who originally reported this issue to us to see if a manufacturer's tool (NxSupervisor) returns the same or not.

[y-yosuke]

Is this a problem occurring only in the last bit?

I am sorry for my lack of understanding.

[y-yosuke]

I've just started reading the codes about this issue, and I am concerned about the following comments in the code of functions readDigitalInput() and readDigitalOutput().

If this information is not old, not wrong or irrelevant, these seem that the last two bits are always returned as 0.

In these comments it is described as 16 bits and there is contradiction with 32 bits.
Is it equivalent to 32 bits for each of the right hand and the left hand 16 bits? I am uncertain about it.

https://github.com/fkanehiro/hrpsys-base/blob/master/python/hrpsys_config.py#L1641-L1689

 def readDigitalInput(self):
        '''!@brief
        Read data from Digital Input
        @see: HrpsysConfigurator.readDigitalInput
        Digital input consits of 14 bits. The last 2 bits are lacking
        and compensated, so that the last 4 bits are 0x4 instead of 0x1.
        @author Hajime Saito (\@emijah)
        @return list of int: List of the values (2 octtets) in digital input register. Range: 0 or 1.
...

def readDigitalOutput(self):
        '''!@brief
        Read data from Digital Output
        Digital input consits of 14 bits. The last 2 bits are lacking
        and compensated, so that the last 4 bits are 0x4 instead of 0x1.
...

[7675t]

Hmm, I'm not sure what this comment says, but
I thought 2 bit from LSB are fixed and not allowed to be changed by users.
That's why I set the MSB to 1 in the first example.

And I didn't check if this happens on the other bits, sorry, I should have, but the client connect something on their I/O port, so I didn't want to break something 😞

[y-yosuke]

I am checking the problem of DIO at Kawada Robotics.

In [1]: b = robot.readDigitalOutput()

In [2]: b
Out[2]: 
[1,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0]

In [3]: b[31] = 1

In [4]: b
Out[4]: 
[1,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 1]

In [5]: robot.wri
robot.writeDigitalOutput          robot.writeDigitalOutputWithMask

In [5]: robot.writeDigitalOutput(b)
Out[5]: True

In [6]: c = robot.readDigitalOutput()

In [7]: c
Out[7]: 
[1,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0,
 0]

[7675t]

What happens if you set all bit to 1 ?

[7675t]

And we should try to call bare API like:

robot.rh_svc.readDigitalOutput()

[y-yosuke]

When the left hand light turns on and keeps on, the function readDigitalOutput() returns 0 except that the first bit returns 1.

In [8]: robot._hands.handlight_l()
dout, mask:
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
[1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2]
Out[8]: False

In [9]: d = robot.readDigitalOutput(); print d
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

[7675t]

What happens when you call

robot.rh_svc.readDigitalOutput()

instead of

robot.readDigitalOutput()

?

[y-yosuke]

When I write all bits as 1, robot.readDigitalOutput() returns 0 except that the first bit returns 1.

In [3]: robot.writeDigitalOutput(b)
Out[3]: True

In [4]: b = robot.readDigitalOutput(); print b
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

In [5]: b= [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]

In [6]: robot.writeDigitalOutput(b)Out[6]: True

In [7]: c = robot.readDigitalOutput(); print c[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

In [8]: robot.writeDigitalOutput(c)
Out[8]: True

In [9]: d = robot.readDigitalOutput(); print d
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

In [10]: 

[y-yosuke]

The engineer of Kawada Robotics explains the phenomenon as follows.

• It seems that the library close to the hardware running on QNX read the buffer (memory?) on the DIO interface board.
• The values except for the 1st bit on the buffer of the DIO board become to 0 after electrical signals are sent to the relay-like element and executed.
• It is correct behavior that the function returns 0 as a specification of the hardware.
• In the past code, instead of reading the DIO buffer, read_digital_output() running on QNX returns the array that kept the value when write_digital_output() worked.

[y-yosuke]

@7675t
robot.rh_svc.readDigitalOutput() worked as same as robot.readDigitalOutput().

[7675t]

Just for confirmation, you mean robot.rh_svc.readDigitalOutput() return values such as:

> ret, dout = rpbot.rh_svc.readDigitalOutput()
> dout
0x8000 (or decimal integer value same as robot.readDigitalOutput()'s  bit list shows)

?

[y-yosuke]

Result of robot.rh_svc.readDigitalOutput()

In [1]: b = robot.readDigitalOutput(); print b[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

In [2]: b= [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]

In [3]: robot.writeDigitalOutput(b)Out[3]: True

In [4]: c = robot.readDigitalOutput(); print c[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

In [5]: ret, dout  = robot.rh_svc.readDigtalOutput()
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-5-5cff8c2e0175> in <module>()
----> 1 ret, dout  = robot.rh_svc.readDigtalOutput()

AttributeError: _objref_RobotHardwareService instance has no attribute 'readDigtalOutput'

In [6]: ret, dout  = robot.rh_svc.readDigitalOutput()

In [7]: dout
Out[7]: '\x01\x00\x00\x00'

In [8]: 

[7675t]

I see, thanks. @y-yosuke
Now, what can we see as a result? Can we conclude it is QNX library side problem?
Anything from @534o while we can reach the hardware ?

[y-yosuke]

@7675t
The cause of this phenomenon is due to QNX library and hardware specifications.

[7675t]

And can they fix it? (I hardly can believe the hardware doesn't return correct output state...)
If not, I think we should remove the function readDigitalOutput() from API, to avoid confusion.

[y-yosuke]

The engineer said that it seems that there were some exchanges with @130s by E-mail in the past related to this case, so he tries to find it.

@130s , do you know something about that?

[y-yosuke]

Anyway it seems that writeDigitalOutput() is working properly.

[y-yosuke]

The engneer of Kawada Robotics said they will fix the QNX library soon.
They think the work itself does not take much time.
It is a matter of time when they can test the fixed code on actual robot during other tests.

[7675t]

I see. Thanks a lot @y-yosuke !

[130s]

Sorry for the delay but thanks for working on this @y-yosuke and I'm glad we narrowed down to the root cause.

[130s]

UPDATE: We got an updated proprietary library from the manufacturer. We'll plan to test it on a real robot, but probably within a month range.

If any of the users are in need of this, please contact either on this ticket, or via TORK support.

---

@7675t @534o could either of you lable this as "bug" (I removed write access to any tork-a repo by mistake)? Thank you in advance.

[130s]

TORK confirmed that with the version 1.2.1 of proprietary library for NXO, this issue is fixed.