Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVT for JAUS IOP testing #2

Open
shiveshkhaitan opened this issue May 7, 2018 · 53 comments
Open

CVT for JAUS IOP testing #2

shiveshkhaitan opened this issue May 7, 2018 · 53 comments

Comments

@shiveshkhaitan
Copy link

How do I get a CONFORMANCE VERIFICATION TOOL (CVT) to test whether I am able to implement the standards or not. I cant find this in internet. Its private I guess, only for NAMC members.
Is there any other way of testing whether I have done stuff correctly?

@atiderko
Copy link
Member

atiderko commented May 8, 2018

You're right, CVT is only for members.
The stuff of iop/ros bridge should be complient. So you can test your stuff against the bridge or use only the components of the bridge ;)

@shiveshkhaitan
Copy link
Author

shiveshkhaitan commented May 17, 2018

Thank you for the information
Are the client services something similar to CVT?

@atiderko
Copy link
Member

Yes, client services are similar to CVT, but without tests of all functionality. The client services uses only relevant parts for bridge.

@shiveshkhaitan
Copy link
Author

So when we will have a CVT will the OCU client be running?

@atiderko
Copy link
Member

Yes

@shiveshkhaitan
Copy link
Author

Then how is ocu client a CVT?

@atiderko
Copy link
Member

a CVT is a tool to test your JAUS/IOP components on the robot. It sends messages (wrong and correct) defined by test profiles and analyze the responses from robot. If they are not as expected CVT reports an error. CVT tries to cover all defined messages of a service/all services.

An OCU client is a component with a set of configured JAUS/IOP services which control the robot and consumes sensor information from this robot. The sensor information is translated to ROS messages, which can be visualized by e.g. rviz or rqt.
OCU client uses not all messages defined by a standard. The supported features are described by a README of each client, e.g. client for GlobalPoseSensor

@shiveshkhaitan
Copy link
Author

Can we please know the difference between a normal service and a client service e.g. Discovery and Discovery Client. It is not very evident in the documentation.

@atiderko
Copy link
Member

Discovery is a service, usually running on robot. DiscoveryClient support the access to Discovery from OCU side.

Perhaps it is easier to understand on GlobalPoseSensorService and GlobalPoseSensorClient.
The GPS position flow is as follow:
ROS NavSatFix -> GlobalPoseSensor (ROBOT) ---- radio --- (OCU) GlobalPoseSensorClient -> ROS NavSatFix

ROBOT or OCU side can be replaced by other IOP compliant software.

@shiveshkhaitan
Copy link
Author

Does this mean that OCU client is a part of the CVT and not our robot?

@atiderko
Copy link
Member

OCU is an Operator Control Unit and means your control software running NOT on your robot.

CVT is a test tool which sends and receives the same massages like OCU, but does not visualize the sensor data and does not send meaningful control commands.

@shiveshkhaitan
Copy link
Author

shiveshkhaitan commented May 19, 2018

How do I use OCU client to create any Event to which my platform manager should respond or a client to query for liveness and make my platform manager respond or any other service apart from Discovery which is described in the documentation?

Do we have to generate "*_sm.cpp" files for all services as mentioned in jaustoolset guide or is there some other way?

I tried to make a Liveness Client using JTS as mentioned in the guide but my liveness service does not respond to it (though the Liveness server created using the guide responds). Is there any way to check what is the message sent in sendJausMessage?

@atiderko
Copy link
Member

Sorry, I don't understand what you try to do.

Do you will use IOP compliant services on robot? Setup an IOP comliant robot? Create your own IOP services?

This ROS/IOP Bridge make your ROS services availabe for IOP compliant OCU's. You need only configure your ROS launch files. See example configuration on robot side

If you want control an IOP compliant robot, you need to setup client service of the ROS/IOP Bridge. See example configuration on OCU side.
To control the robot from OCU, you need to get access control. For this purpose you need the "AccessControl" rqt plugin from iop_rqt_accesscontrol_fkie. See example

If you still want create your own plugin see docu

@shiveshkhaitan
Copy link
Author

shiveshkhaitan commented May 20, 2018

What I intend to do is that I already have a ROS robot ready. Now I want a JAUS layer over my robot which can respond to CVT e.g. if CVT queries for liveness, then my robot should respond to it. I dont think I will have to implement my own services because most of the services which I require are already present in the package. I am just unable to figure out a way to test them.

Creating the launch file as described in https://github.com/fkie/iop_core/blob/master/doc/howto_minimal_config.md
I think the services are already created. When I echo /iop_system I get the list of services which means that the Discovery service works. But what about the other services e.g events, liveness etc. How do I make OCU test other services so that my robot responds to the queries in appropriate manner

@atiderko
Copy link
Member

If you have setup the bridge for the robot and has already discovered it, most of work is done.

How can you test it:

  1. Setup a component with client services for services you uses on your robot:
    1.1. e.g. if you configured on you robot PrimitiveDriver, you need need PrimitiveDriverClient on your OCU component
    1.2. you need also rqt with AccessConrol Plugin. This plugin display all discovered robots using '/iop_system' topic by default.

  2. Setup wireshark to see which JAUS messages are exchanged between your components.
    2.1. You can use this wireshark dissector or another one...
    2.2. change JTS configuration file to receive all JAUS messages on loopback. This file should be included in your config, e.g <param name="jaus_config" value="$(find jaustoolset)/cfg/nm.cfg"/>. In nm.cfg set EnableLoopback to 1.

  3. In rqt-AccessControl click on discovered robot name to trigger the event creation to get JAUS/IOP reports from robot.
    3.1 What happens:
    3.1.1 AccessControl-plugin sends a command to the OCU component through /cmd_ocu topic.
    3.1.2 OCU component requests access control by the robot.
    3.1.3 On accept events for different reports are created. You can also change in your OCU component to request the reports use_queries .
    3.2 How can I see what happens:
    3.2.1 Success or errors are displayed in AccessControl plugin.
    3.2.2 Wireshark for a full info.
    3.2.3 screen/log output of the ROS node (OCU component) (increase log level for different plugins).
    3.2.4 ROS topic output of the ROS node (OCU component).

There is no guarantee you pass all of CVT tests! CVT sends a command and expect what the report contains the predifined values. If this values are different, you can change most of these by parameter, e.g. access_timeout or events_timeout.

Currently there is no client for liveness service, so no request are generated for it, but the service itself pass the CVT test.

@shiveshkhaitan
Copy link
Author

shiveshkhaitan commented May 20, 2018

I am able to connect to my robot from the rqt access control and when I give it a "ocu/cmd_vel" my robot moves (in simulation). Does it mean that the jaus ros bridge is properly setup and it is something like CVT controlling the robot? Or is it only ros messages because superficially, there isnt anything like JAUS which I can see. When I echo /is_controlled it shows "true".

And /iop_system list all my services even before I access control my robot from rqt. Is that suppose to happen?

@atiderko
Copy link
Member

This sounds good!

  • /iop_system shows all discovered robots without access control from rqt.
  • /is_controlled shows the access control state (true or false) if access control was granded to rqt or other OCU or test tool CVT
  • the ROS/IOP bridge hides all JAUS stuff. Only way to see JAUS messages is using wireshark.

@shiveshkhaitan
Copy link
Author

shiveshkhaitan commented May 21, 2018

I could set up wireshark and I know its configured for JAUS messages because when I play an example .pcap file, I can read decoded JAUS messages. But when I launch my launch files, I dont get any JAUS messages. All of them show TCP Protocol. How do I get the Jaus messages? I have edited nm.cfg file to change "EnableLoopback" to 1 as mentioned in guide.

Also I noticed that when I launch jaus_node_manager it shows "Unable to bind to UDP port 3794" and "Unable to bind to UDP Loopback port 55555". Can this be a possible reason. What do I do about it?

Another thing which I noticed is that of I edit nm.cfg file and type anything gibberish, jaus node manager launches without any error other than the UDP port one. I am certain that I am editing the correct nm.cfg file which is loaded with JTSNodeManager. How is it possible?

My jaus node manager launch file
node name="jaus_node_manager" pkg="node_manager_fkie" type="script_runner.py" output="screen"
param name="script" value="$(find jaustoolset)/JTSNodeManager $(find jaustoolset)/cfg/nm.cfg" /
param name="jaus_config" value="$(find jaustoolset)/cfg/nm.cfg"/
/node

And after I get wireshark working I can see the jaus messages, but my robot will not respond on its own, right? The client will have to query something like "set emergency" or anything else. rqt access is only for cmd_vel. How do I control the other things.

@atiderko
Copy link
Member

The "Unable to bind to UDP port 3794" error occurs if the JTS node manager was launched twice without to stop the first one. Somethime it does not stop for some reason... Search for process ps -ax|grep JTS and kill this.

The easiest way to see that the right file was loaded is to change the LogMsgLevel_. If you install your build code it is perhaps a different location of the nm.cfg.

Launch configuration for JTS node manager:

    <node name="jaus_node_manager" pkg="node_manager_fkie" type="script_runner.py">
        <param name="script" value="$(find jaustoolset)/JTSNodeManager $(find jaustoolset)/cfg/nm.cfg" />
        <!-- <param name="stop_script" value="pkg://iop_builder_fkie///jaus_node_manager.sh stop" /> -->
    </node>

Launch for other nodes to uses the right JTS configuration file:

<launch>
    <param name="jaus_config" value="$(find jaustoolset)/cfg/nm.cfg"/>
    <node name="iop_platform_manager" pkg="iop_component_fkie" type="iop_component" ....
    :
    :

If after all of this wireshart does not shows the JAUS messages, try to change the "EnableLoopback" to 2...

To control other things you need on the robot the right service, .e.g.
iop_global_waypoint_driver_fkie: "GlobalWaypointDriver", on OCU the right client iop_client_global_waypoint_driver_fkie: "GlobalWaypointDriverClient" and a ROS tool to generate the waypoint. It can be rviz, your ROS package or something else.

@shiveshkhaitan
Copy link
Author

shiveshkhaitan commented May 21, 2018

I get the jaus messages now but only for query identification in wireshark. Even though my robot is moving by /ocu/cmd_vel in rqt, there are no jaus messages in wireshark

@atiderko
Copy link
Member

I did not tested the dissector file. Do you see other UDP messages which are not marked as JAUS?

@shiveshkhaitan
Copy link
Author

shiveshkhaitan commented May 21, 2018

Yes. And the UDP and Jaus messages have the same source and destination. Dont know if that matters

@atiderko
Copy link
Member

atiderko commented May 21, 2018

query identification message are the only message send using multicast. All other messages are send as unicast message. By communication on the same host the unicast messages are not going through the network interface by default. You can try to launch the robot stuff on different host. If it works, the loopback device does not configured properly or wireshark does not listen on the right interface.

@shiveshkhaitan
Copy link
Author

Thank you for the information

@shiveshkhaitan
Copy link
Author

shiveshkhaitan commented May 21, 2018

Is 'set local pose' code not already written because the 'updateLocalPoseAction(SetLocalPose msg)' function is empty
If i have to write it, then I just edit 'updateLocalPoseAction(SetLocalPose msg) in LocalPoseSensor_ReceiveFSM.cpp and then catkin build, thats it right? Then whenever a SetLocalPose msg will be sent by client will the function would be automatically called?

Where do I get the list of all data values SetLocalPose msg holds and extract them

@atiderko
Copy link
Member

You're right, it is currently not implemented!

You can add your code to updateLocalPoseAction(SetLocalPose msg) in LocalPoseSensor_ReceiveFSM.cpp

You can test it, by adding a ros::Subscriber to LocalPoseSensorClient_ReceiveFSM.cpp in iop_client_local_pose_sensor_fkie. In callback you need to send a Jaus message SetLocalPose to p_remote_addr.

The description of the message you find on http://openjaus.com/htmlDoc/index.html in Mobility ServiceSet.

The c++ message classes are located in catkin_ws/build/iop_local_pose_sensor_fkie/jaus/... or catkin_ws/devel/include/urn_jaus_jss_mobility_LocalPoseSensor/...

@shiveshkhaitan
Copy link
Author

Thank you for the information

@shiveshkhaitan
Copy link
Author

shiveshkhaitan commented May 21, 2018

In the readme for iop_client_local_waypoint_driver_fkie the subscribe topic for poses is written as cmd_local_pose. I guess it should be cmd_pose as that is the topic subscribed in the LocalWaypointDriverClient_ReceiveFSM

And in LocalWaypointDriverClient_ReceiveFSM.cpp in line 257 it should be pose_out.pose.position.y instead of pose_out.pose.position.x

Pls correct me if I am wrong

@atiderko
Copy link
Member

Thanks!

I changed cmd_pose to cmd_local_pose in iop_client_local_waypoint_driver_fkie. There is also cmd_global_pose in _iop_client_global_waypoint_driver_fkie.

I fixed also the error LocalWaypointDriverClient_ReceiveFSM.cpp in 257.

@shiveshkhaitan
Copy link
Author

As mentioned in https://github.com/fkie/iop_core/blob/master/doc/howto_minimal_config.md we set services in platform manager which is our robot. Why do we include the client services in platform manager. Shouldnt they be only in OCUClient because OCU client is controlling the robot and not the robot itself?

@atiderko
Copy link
Member

There are only few client services in platform manager ("DiscoveryClient" and "EventsClient"). We need only "DiscoveryClient" to register the service in Discovery service. Theoretically, in platfrom manager we can register the services direct by Discovery service. In real there is no interface for that...

You need "DiscoveryClient" also in each component on the robot to discover Discovery service and register own services.

@shiveshkhaitan
Copy link
Author

If I am using LocalWaypointDriver then do I include LocalWaypointDriverClient in both platform manager and OCU client or only in OCU client.

@atiderko
Copy link
Member

in platform_manager you include iop_global_waypoint_driver_fkie: "LocalWaypointDriver"
in ocu_client you include iop_client_global_waypoint_driver_fkie: "LocalWaypointDriverClient"

@shiveshkhaitan
Copy link
Author

shiveshkhaitan commented May 22, 2018

Whenever I set /ocu/cmd_mgmt_emergency which is as I suppose the command to set robot in emergency, rqt shows

Services with warning state:
Client 150.64.200:
urn:jaus:jss:mobility:PrimitiveDriver[133.64.15]: NOT_AVAILABLE
urn:jaus:jss:mobility:LocalPoseSensor[133.64.15]: NOT_AVAILABLE
urn:jaus:jss:mobility:GlobalPoseSensor[133.64.15]: NOT_AVAILABLE
urn:jaus:jss:environmentSensing:RangeSensor[133.64.15]: NOT_AVAILABLE
urn:jaus:jss:iop:PathReporter[133.64.15]: NOT_AVAILABLE
urn:jaus:jss:mobility:LocalWaypointListDriver[133.64.15]: NOT_AVAILABLE
urn:jaus:jss:mobility:LocalWaypointDriver[133.64.15]: NOT_AVAILABLE
urn:jaus:jss:mobility:GlobalWaypointListDriver[133.64.15]: NOT_AVAILABLE
urn:jaus:jss:mobility:GlobalWaypointDriver[133.64.15]: NOT_AVAILABLE
And after that I am unable to connect to my robot again. Does not seem to be a problem on the robot side because when I publish true or false in /is_emergency directly, nothing like this happens. What can be the cause?

@atiderko
Copy link
Member

In emergency state you can't control robot.
You should set /ocu/cmd_mgmt_emergency to false to be able to get access again.
Perheps you need to click an view to say to ocu_client components to which address you senden emergency commands

@shiveshkhaitan
Copy link
Author

shiveshkhaitan commented May 23, 2018

I dont get control over my robot again after I get to emergency once even on setting /ocu/cm_mgmt_emergency false. I have to release control and get access control again by clicking on my robot beside 'view' in rqt. Why does this happen?

@shiveshkhaitan
Copy link
Author

Whenever I use "local waypoint list driver" although the waypoints are executed correctly I receive this message consistently "list element rejected by 133.64.15: request_id: 59, reject code: 5". How do I get information about this error code 5?

@atiderko
Copy link
Member

I believe this error comes from RejectElementRequest(ListManager). You find the information on http://openjaus.com/htmlDoc/index.html. If I find time I will check the LocalWaypointListDriver again. Is this error occurs each time?

@atiderko
Copy link
Member

atiderko commented May 23, 2018

  1. The protocol for Management service says, that the control should be released on emergency.
  2. If control was released the ocu_client_component forget the address of remote component. (Current implementation)
  3. This is the reason, why you need click in rqt on release and then on view. By click on view the ocu_client_component become the address of remote address.

I think, this is not really intuitive... I need an idea for a better handling...

@shiveshkhaitan
Copy link
Author

Yes the error shows up everytime. But the waypoints are perfectly achieved. Doesnt seem to be a major problem then.

@shiveshkhaitan
Copy link
Author

I have edited LocalWaypointDriver_ReceiveFSM.cpp as per my requirement to set the local pose.

Which function in LocalWaypointDriverClient_ReceiveFSM.cpp do I have to use to subscribe to the set pose command?

@atiderko
Copy link
Member

LocalWaypointDriverClient subscribed to 'cmd_local_pose'. If PoseStamped is received the pCmdPose will be called. In this method PoseStamped is translated to JAUS message SetLocalWaypoint and send to LocalWaypointDriver.

@atiderko
Copy link
Member

I've changed the behaviour on emergency in ocu client. The component address with emergency state will now be stored and it is easier to clear the emergency state.

@shiveshkhaitan
Copy link
Author

shiveshkhaitan commented May 31, 2018

Thank you for the help
How can I change the presence vector of a msg. I want to change the presence vector of reportlocalpose msg. When I use p_report_local_pose.getBody()->getLocalPoseRec()->setPresenceVector(323) it gives an error ...setPresenceVector(unsigned int) is protected

Also how can I change the service versions. Some of the services have version 1.1 but I want 1.0
How can I can I change them so that at least CVT reads it as 1.0

@atiderko
Copy link
Member

atiderko commented Jun 1, 2018

you are welcome
In most messages, the presence vector is changed by the message them self as soon as the corresponding values are set. By other messages the setPresenceVector is not protected.

You can change the version of services in plugin_iop.xml which is located in each package.

@shiveshkhaitan
Copy link
Author

shiveshkhaitan commented Jun 1, 2018

I want to set the presence vector of reportlocalpose in robot side according to the presence vector requested by reportlocalpose from client side. How do I do this?

Like in client for localpose we set a presencevector to 65535. Now how do I detect on the robot side that the query msg has a presence vector of 65535 and set my reportlocalpose presence vector accordingly

@atiderko
Copy link
Member

atiderko commented Jun 1, 2018

You can't change the presence vector of ReportLocalPose!

On robot side you have to look at each bit of the presence vector and decide which information should be reported. If first bit is set you have to report the X position. So you set it:

p_report_local_pose.getBody()->getLocalPoseRec()->setX(x);

For presence vector meaning see:
http://openjaus.com/htmlDoc/triggers/ReportLocalPose-4403.html

The value of 65535 was chosen because of type of presence vector. It is enough to set it to 255 to get all values of report local pose.

Currently it is not tested, because in the origin JSIDL the query message is not passed to the function. To get access to the query you need to change the LocalPoseSensor.xml in iop_builder_fkie. And pass instead of 'ReportLocalPose' a msg. (see e.g. GlobalWaypointDriver.xml) Than run catkin build and look for changes in LocalPoseSensor_ReceiveFSM.h.diff and LocalPoseSensor_ReceiveFSM.cpp.diff in iop_local_pose_sensor_fkie package.

@atiderko
Copy link
Member

atiderko commented Jun 1, 2018

It has not effect on robot side in this bridge, but other IOP compliant robots should look at the presence vector.
By setting presence vector in client you can reduce the message size transmitted over the radio link, because you are not interested in e.g. orientation or hight(Z) values. Not in this implementation, but perhaps in other IOP compliant implementation.

@shiveshkhaitan
Copy link
Author

Is there a reason why event for Report Control is not implemented in Access Control?
Just adding these lines in setupNotifications() will do the job right?
pEvents_ReceiveFSM->get_event_handler().register_query(QueryControl::ID);
pEvents_ReceiveFSM->get_event_handler().set_report(QueryControl::ID, &response); //response is the msg used in function sendReportControlAction()

@atiderko
Copy link
Member

atiderko commented Jun 4, 2018

there is no reason!
yes, you can add these two lines, but you have also update the &response on each change of the controller to support onchange events. This can be in storeAddressAction, setAuthorityAction and sendReportTimeoutAction

@shiveshkhaitan
Copy link
Author

shiveshkhaitan commented Jun 4, 2018

I dont get what changes do I have to do in these three functions. What I did was added the two lines in setupnotifications and did changes in accesscontrolclient. I could get it working(The function for handlereportcontrol was being called at desired rate). What changes do I have to do in storeAddressAction, setAuthorityAction and sendReportTimeoutAction?

@atiderko
Copy link
Member

atiderko commented Jun 4, 2018

you have to add the content of sendReportControlAction to update &response and also trigger onchange event with pEvents_ReceiveFSM->get_event_handler().set_report(QueryControl::ID, &response);

something like this:

	ReportControl response;
	unsigned int sid = 0;
	unsigned int nid = 0;
	unsigned int cid = 0;
	if (p_current_controller.get() != 0) {
		sid = p_current_controller.getSubsystemID();
		nid = p_current_controller.getNodeID();
		cid = p_current_controller.getComponentID();
	} else if (p_emergency_address.size()) {
		JausAddress eaddr(*p_emergency_address.begin());
		sid = eaddr.getSubsystemID();
		nid = eaddr.getNodeID();
		cid = eaddr.getComponentID();
	}
	response.getBody()->getReportControlRec()->setSubsystemID(sid);
	response.getBody()->getReportControlRec()->setNodeID(nid);
	response.getBody()->getReportControlRec()->setComponentID(cid);
	response.getBody()->getReportControlRec()->setAuthorityCode(p_current_authority);
        this->response = response;
        pEvents_ReceiveFSM->get_event_handler().set_report(QueryControl::ID, &this->response);

@shiveshkhaitan
Copy link
Author

Thank You for the help

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants