Improving Conversion of Array-like Ros-Messages

[iml-dlux]

Firos currently cannot convert an object into the correct Ros-Message, which look like:

Header header

unit8[] x
float64[] y
MyVeryOwnMsg[] mvom

It looks like the implementation is missing for such cases in:

firos/scripts/include/ros/rosutils.py

Lines 36 to 53 in 36e1e7e

	def obj2Ros(obj, msgInstance):
	## \brief Map a dict to Ros Object
	# \param dictionary
	# \param Ros Object instance
	if hasattr(msgInstance, '__slots__'):
	for key in msgInstance.__slots__:
	if hasattr(obj, key):
	setattr(msgInstance, key, obj2Ros(getattr(obj, key), getattr(msgInstance, key)))
	elif type(obj) is dict and key in obj:
	setattr(msgInstance, key, obj2Ros(obj[key], getattr(msgInstance, key)))
	# TODO DL Remove?
	# if key in obj:
	# setattr(msgInstance, key, obj2Ros(obj[key], getattr(msgInstance, key)))
	else:
	if type(obj) is dict:
	raise Exception("Not a primitive")
	msgInstance = obj
	return msgInstance

Also the 'Definition file class' which is loaded on line

firos/scripts/include/ros/topicHandler.py

Line 166 in 36e1e7e

msg = instance["class"]()

might be errorneos in this case

Debugging to the Point, where the data of msg is replaced by the actual values (obj2Ros) shows, that the actual msg on that point is a empty list, but the obj still contains information.

[iml-dlux]

Setting a Breakpoint on the added Lines in 332fe5a shows that the msgInstance is empty and the obj still contains content.

[iml-dlux]

In commit e4093ce the Objects received from CB are parsed differently now. With the Object-Converter 'Type'-Information are saved on the CB, so that the parsing to a ROS-class can happen without prior knowledge about the actual ROS-class.

This parsing still needs to be tested..

( for linking)

[Luxxii]

In StackOverflow, the following (alternative) representation of arrays is shown:

Here the alternative representation:

"pressure": {
    "value": [720, 500],
    "type": "Integer"
}

Instead of using Integer, we should use standard json-DataTypes. In Addition to that, we should find more documentation about such a representation before Implementation.