rticommunity / rticonnextdds-connector

RTI Connector for Connext DDS is a lightweight technology that enables DDS data to be accessed with Javascript (Node.js), Python, and Lua.
Other
56 stars 33 forks source link

Writing data of different type (CON-24) #39

Open ilya1725 opened 7 years ago

ilya1725 commented 7 years ago

I have the following data structure defined in the XML file for commands:

<struct name= "MotorCommand">
  <member name="current_A" type="double"/>
</struct>

When I explicitly set the data as double, like this:

{'motor': [{"current_A": 25.0}]}

The command is being set fine. However, if the data is set like this:

{'motor': [{"current_A": 25}]}

it isn't sent. I use the

    self._command_writer.instance.setDictionary(command)
    self._command_writer.write()

python code to write DDS commands.

I have two questions:

  1. Is it hard requirement that the data types in the dictionary must be exactly as declared in the XML file?
  2. Is there a way to get some sort of error status from self._command_writer.write()? It is very inconvenient/dangerous for the API to just accept a command and provide no status back.
gianpiero commented 7 years ago

Hi @ilya1725 ,

Is it hard requirement that the data types in the dictionary must be exactly as declared in the XML file?

It should work. The scripting layer will try to convert any number to the right type. Can you send a reproducer so i can debug the issue?

Is there a way to get some sort of error status from self._command_writer.write()? It is very inconvenient/dangerous for the API to just accept a command and provide no status back.

I agree: we are aware of this issue, we just did not get around of doing it yet. I created an internal request CON-24 (for future reference)

ilya1725 commented 7 years ago

An example file attached. It is modified writer.py example code. I just modified the ShapeType data structure. Writing data directly using output.instance.setNumber works fine. But if I use a dictionary, then not setting a double value either doesn't transmit it or transmits it as 0.0. I use the RTI administration console to see the values.

output.write() does return some value. Is there any documentation on those values?

example.zip

gianpiero commented 7 years ago

Hello @ilya1725 ,

The return value for now has not meaning. We will add return code when we implement CON-24.

As for the example you attached, let me explain what is happening:

In the example, if I set the dictionary in this way:

values = {
    'color': "-test-",
    'x': 2,
    'y': 23.7,
    'shapesize':345
    }

Everything works. The receiver gets all the data (including shapesize = 345)

But if i set the shapesize field as a double:

values = {
    'color': "-test-",
    'x': 2,
    'y': 23.7,
    'shapesize':345
    }

But if i change the dictionary to be

values = {
    'color': "-test-",
    'x': 2,
    'y': 23.7,
    'shapesize':345.0
    }

The receiver won't get shapesize (or better it will be set to '0').

The problem is in the way the json parser works. shapesize is defined as a long in the XML file. But your dictionary has a double. So we do not set that field.

As for the write() operation, unfortunately we are not reporting errors all the way to the python layer yet.

The setNumber api works because it threats all the number the same way and does a conversion internally.

So is not the write operations that fails (it a single operation for the all sample.. not field to field) but the set that fails.

Does the explanation make sense to you?

ilya1725 commented 7 years ago

@gianpiero it does explain the error, thank you. My concern was that write() would silently eat the values and won't report anything. I'll have to be more diligent with the types and I'll wait for the proper write() implementation.

gianpiero commented 7 years ago

@ilya1725 i think we have to decide internally what to do with the types.. is it an error to try to set a long using a json_double? or we should do it anyway (like we do with setNumber()) ? and, if it is an error, we should report it when you try to set it!

This is very good conversation: thanks! I will bring this up with the team!