Dev_MessageHandling
In the ROS# Unity package, joint state subscription and publication is handled by the joint state patcher. Depending on the selection from the component editor (subscribe or publish), the joint state publisher or the joint state subscriber component is added to the game object. As the name suggests, they handle the joint state data transfer with the ROS side. But the published joint states should contain the latest joint info and the subscribed joint states should be presented on the Unity scene immediately, and these tasks are performed by the joint state writer and joint state reader. The writer couples with the subscriber, and whenever a new message is received, the joint state subscriber triggers the joint state writer, and the writer updates the urdfJoint class immediately. Similarly, the reader couples with the publisher, and at each fixed time step, joint state publisher triggers the reader to get the latest joint states. This whole process is done automatically: When the joint state patcher is triggered, a publisher or subsriber component is added with the readers or writers of each non-fixed joint.
Joy messages in ROS are a convenient way to handle robot motion. Similar to the joint state classes in ROS#, Joy Subscriber and Joy Publisher are paired with Joy Writer and Joy Reader, respectively. As the name suggests, Joy Publisher triggers the Joy Axis Reader, which reads directly from Unity's Input Manager. But you are not limited to this: Joy Axis Reader implements the highly flexible IAxisReader interface, so you can write your own Joy Readers. See for example the third part of the Gazebo Simulation Scene, where a custom touchscreen joystick is used to publish joy data to ROS and Gazebo.
On the other hand, Joy Axis Writers directly or indirectly modify a specific joint based on the Joy Data input. This joy data can be captured from the ROS side using the Joy Subscriber, or it can be captured directly within Unity's Input Manager using the Joy Axis Input Passer. These two classes, Joy Subscriber and Joy Axis Input Passer, capture the Joy data and trigger any type of Joy Axis Writer attached to them. There are two built-in joy writers in ROS#.
Without simulation, if the goal is to directly modify a joint using Joy data, Joy Axis Transform Writer is the Joy Axis Writer implementation to choose. Based on the input, it doesn't simulate the joint, but directly triggers the joint state writer within the joint limits, then the joint state writer triggers the urdfJoint change. See the Animate Robot Model In Unity as an example.
If the goal is to simulate a joint with proper torque and velocity values, then the Joy Axis Joint Motor Writer is the Joy Axis Writer to choose. Based on the settings in Unity's built-in hinge joint component (which should be added automatically when importing the urdf), the Joy Axis Joint Motor Writer triggers a state change and sets the target joint velocity for the hinge joint motor component. Then, unlike the Joy Axis Transform Writer, it doesn't trigger the Joint State Writer, but updates the urdfJoint itself. See R2D2's wheel actuation in the Unity Simulation Scene as an example.
In ROS#, the LaserScanSubscriber and LaserScanPublisher work in conjunction with LaserScanReader and LaserScanWriter to manage these messages.
The LaserScanSubscriber component is responsible for receiving laser scan data from the ROS system. When a message is received, it passes the data to the LaserScanWriter. This writer processes the data and makes it available to the Unity environment. The writer updates visualizers or other relevant components that rely on the laser scan data.
When the subscriber receives the message, it triggers the LaserScanWriter, which then updates the internal Unity components by converting the ROS data into usable Unity structures. The scan data includes the range and direction of each laser beam.
On the publishing side, the LaserScanPublisher works with the LaserScanReader to gather data from the Unity environment and send it to ROS as a laser scan message. The LaserScanReader generates a simulated laser scan by casting rays in the Unity scene, which are processed to detect distances to objects in the environment.
The reader creates an array of rays based on parameters such as the number of samples, range limits, and scan angles. It then casts each ray and records the distance to any objects detected, simulating the behavior of a real-world sensor. The scan data, including angles and ranges, is collected and passed to the publisher, which then sends it to ROS.
The entire process, from generating the scan data in Unity to sending it as a message in ROS, occurs automatically at regular intervals defined by the FixedUpdate() method. This ensures that the laser scan data is continuously updated in both Unity and ROS.
© Siemens AG, 2017-2024