All topics are empty

[SirNickelston]

When I try to print the content of the different topics published by the all_in_one_publisher.py via ROS1 commands like rostopic echo or rostopic hz on the Linux side of the software construct, they have no content. So somewhere along the software chain the information from FS19 (e.g. clock, odom, imu, ...) gets lost.

I have to use their software for my bachelor thesis, but now I'm trying to get behind the cause of this problem for more than two weeks. I just do not know what to do anymore.

I hope that this page is still maintained and that you can help me. The all_in_one_publisher.py runs without error messages. It connects to the roscore, which is hosted on virtual box with Ubuntu 20.04.6 LTS, as well as to the Farming Simulator the moment it starts to share its data with the command rosPubMsg true.
The topics are visible in the rqt_graph of the Ubuntu machine as soon as the all_in_one_publisher.py is running. However, the topics remain empty in terms of content, regardless of the actions in Farming Simulator 19.
At the moment, I suspect that the problem could be with the pipes. But it is difficult to check this, because as a mechanical engineering student I lack the technical expertise.
In order to verify this, I have tried to create my own named pipes with the same name. However, those are not accepted by all_in_one_publisher.py or even other publishers, probably because of their different handle (despite the same settings).

I sincerely hope that you can help me to get the software package running.
Do you maybe have a complete installation you could share or an idea where the root of the problem lies?

Thanks a lot

[gavanderhoorn]

I have to use their software for my bachelor thesis, [..]

who is they here?

I hope that this page is still maintained and that you can help me.

it isn't (maintained), but let's see what we can do.

When I try to print the content of the different topics published by the all_in_one_publisher.py via ROS1 commands like rostopic echo or rostopic hz on the Linux side of the software construct, they have no content.

What do you mean exactly by "they have no content"?

Do you receive empty messages but you do receive messages (fi: empty tf_msgs/TFMessages, containing no transforms).

Or does rostopic echo show no output whatsoever? It just 'hangs' after rostopic echo /some_topic?

The all_in_one_publisher.py runs without error messages. It connects to the roscore, which is hosted on virtual box with Ubuntu 20.04.6 LTS, [..]

Please describe your setup with more detail.

You have a VBox VM, and I guess a regular Ubuntu Linux host running that VM?

How did you configure your networking? Especially between the VM and your host?

If it's using the default NAT configuration, your problem is likely not a problem with modROS, but a regular ROS problem.

Switch the VM to bridge (maybe host only will also work) and make sure to configure your ROS_IP correctly on all hosts.

In essence, you need to treat FS19+modROS as a separate 'machine' in a ROS multi-machine setup. If ROS_IP is not correctly configured, or the firewall on the Windows side or on the Ubuntu side is blocking traffic, or your using NAT-networking between the VM and your host, things will not work (reliably).

---

Another option could of course be that some of the hard coded paths are not correct for your FS19 installation.

That would be something I can't help you with, as I don't know how you've installed things on your end.

[gavanderhoorn]

So summarising:

• your host is Win11
• your VM platform is Virtualbox
• the guest is Ubuntu Focal
• you have a Noetic ROS 1 install in the guest
• you have configured the Ubuntu VM to use bridged networking
• you can ping vbox_vm from Win11
• you can't ping win11_host from Ubuntu-inside-Vbox

Correct?

There are two ways to approach all of this:

1. you setup a bridged network (which you say you already have): the VM guest would get an IP address in the same range as whichever network card you bridged with
2. use a host-only network: the VM guest will get an IP address in a 'private' range, and network traffic will only flow between the host and the guest

In both cases no NAT will be used. You really want to avoid NAT with ROS (1 or 2, doesn't really matter).

In both cases you should be able to ping in both directions (ie: host should be able to ping guest, and vice-versa).

If all of that is OK and working, the configuration on the ROS sides would be:

• host (ie: Win11):
  • ROS_IP=<ip address of the host-NIC the guest can reach>
  • ROS_MASTER_URI="http://<ip address of the guest-NIC>:11311"
• guest (ie: Ubuntu):
  • ROS_IP=<ip address of the guest-NIC the host can reach>
  • if you haven't changed it, you can leave the ROS_MASTER_URI to its default (probably "https://localhost:11311")

Make sure to restart whatever shells / terminals you have running after making changes to env vars, or they won't be picked up.

Note: unless you make these settings permanent, you need to set or export these in every terminal, and every time you start a new Bash/cmd session.

---

At this point things either start working, or you still don't see any output from rostopic echo (note: you don't need to "drive around", just subscribe to /clock and make sure FS is not paused).

If things don't work:

• just for the test: disable the Ubuntu firewall (sudo ufw disable): test again, if things now work, UFW was blocking the traffic. Read up on how to add rules allowing your ROS traffic through and re-enable, or permanently disable UFW (verify this is OK to do in your case)
• just for a test: disable the Windows firewall: I don't know whether your laptop is your own, but if it is, this should be possible. If it's managed by your organisation, this might not be possible. Something for you to figure out. If things start working: Windows firewall was interfering. Configure it to allow ROS traffic through.
• forget about FS19 and modROS for a bit: write a simple Python rospy publisher (the one from the rospy tutorials publishing a std_msgs/String would do) and run it on your Win11 host (don't forget to setup ROS_IP and ROS_MASTER_URI as explained above and to run roscore on your Ubuntu guest before starting the script). Now run rostopic echo /whatever_topic_name_you_publish_to_from_win11. If this also doesn't work, you have more fundamental problems. If it does work, the problem would appear to be either in modROS and/or all_in_one_publisher.py.

If after these tests/changes things still don't work, I'm afraid remote debugging/diagnosing would not work any more. I'd suggest perhaps using Wireshark to check whether network traffic is arriving at your guest, and sent by Win11.

It could also be your Steam install of FS19 is different from the setups we tested, and paths need to be changed, or something else. Again, I would not know.

[SirNickelston]

Thanks for the support.
With your tips, I managed to ping in both directions. So the host finds the guest and vice versa. The error was in the Windows firewall. It allowed all outgoing traffic, but blocked all incoming one. After allowing this in the advanced settings, I was able to solve this problem thanks to your help.

The network settings of the VB now look like this:

• Type: Network Bridge
• Name of the network controller: Realtek PCIe GbE Family Controller

I also adjusted the configuration on both sides accordingly. I was not aware before that the additional variable ROS_IP is needed. Thanks for this information.
With the ip4 address of the host machine [134.169.70.98] and the ROS_MASTER_URI of the VB Linux guest named UBUNTU20 the configuration looks like this:

• Host (Windows 11)
  • ROS_IP=134.169.70.98
  • ROS_MASTER_URI=http://Ubuntu20:11311/
• guest(Ubuntu)
  • ROS_IP=134.169.70.98
  • ROS_MASTER_URI=http://Ubuntu20:11311/

After I restarted all systems, set the variables and checked them separately, unfortunately the problem described earlier is still present. Therefore I was very grateful for the section "if things dont work".

• Disabling the Ubuntu and then also Windows firewall unfortunately did not achieve the hoped for success. I was able to make these changes without further consultation, as I am still tied to my private computer at the moment.
• The opportunity to forget FS19 and the modROS I have only too gladly perceived😅. My previous skills with ROS were limited to ROS2, so I had to briefly look into writing a ROS1 publisher. As recommended, I wrote a simple string publisher which publishes under the topic /chatter "Hello World" with timestamp. Here is the short source code:

import rospy

from std_msgs.msg import String


def talker():

    pub = rospy.Publisher('chatter', String, queue_size=10)

    rospy.init_node('talker', anonymous=True)

    rate = rospy.Rate(10) # 10hz

    while not rospy.is_shutdown():

        hello_str = "hello world %s" % rospy.get_time()

        rospy.loginfo(hello_str)

        pub.publish(hello_str)

        rate.sleep()

  

if __name__ == '__main__':

    try:

        talker()

    except rospy.ROSInterruptException:

        pass

• To my delight, this worked right away. The self-written publisher ran in the Windows Powershell and I could follow the sent messages on the Linux side with rostopic echo /chatter. I did not change the roscore or the network settings compared to FS19 / the all_in_one_publisher.py.
  I would conclude that the error must be somewhere on the Windows side with the mod? The communication between Windows and Linux via ROS obviously works. The topics are also created by the all_in_one_publisher.py, but it doesn`t seem to get any information from FS19 / modROS.

• Are there any ways to test where on this route the data is lost, or if the mod records and passes it on at all?

• Is there a way to check if the data from the pipe arrives at the all_in_one_publisher.py?

• Could you tell me the version of FS19 you developed and tested the mod on at the time, so I can rule out the game internal updates as a source of errors? Staying with this topic, is it "normal" that the game internal screen of the mod selection talks about version 0.0.2.0?

• When I wanted to test the cm_vel_subscriber I got the error message that memorpy is missing. I replaced this in the source code with memorpy3, but the cm_vel_subscriber does not run. According to my understanding of the program structure this should not have any effect on the publisher situation? I also have some questions about the use of Memorpy, but more important for me is that the susbcribing of topics works.

Thanks for the effort.

PS. I have noticed that there are no DMs on github. If I have more official questions regarding the usage I would like to contact you with my Uni Mail, if this is ok for you. Im from the TU Braunschweig in Germany.

[gavanderhoorn]

I also adjusted the configuration on both sides accordingly. I was not aware before that the additional variable ROS_IP is needed. Thanks for this information. With the ip4 address of the host machine [134.169.70.98] and the ROS_MASTER_URI of the VB Linux guest named UBUNTU20 the configuration looks like this:

* Host (Windows 11)
  * `ROS_IP=134.169.70.98`
  * `ROS_MASTER_URI=http://Ubuntu20:11311/`
* guest(Ubuntu)
  * `ROS_IP=134.169.70.98`
  * `ROS_MASTER_URI=http://Ubuntu20:11311/`

Are you sure this is correct?

I would expect the VBox guest and the Win11 host to have different IPs.

And I would also recommend to not use any hostnames whatsoever. So even in ROS_MASTER_URI, just use IP addresses.

I am still tied to my private computer at the moment.

that could be, but from the IP address it would appear you are using the universities network, and I would be surprised if they would be happy about a VirtualBox instance requesting an IP address.

Perhaps a host-only network configuration would be better.

I would suggest to verify your ROS_IP and ROS_MASTER_URI settings and try again.

PS. I have noticed that there are no DMs on github. If I have more official questions regarding the usage I would like to contact you with my Uni Mail, if this is ok for you. Im from the TU Braunschweig in Germany.

I'm not sure what you mean by "more official questions".

Posting here on the Discussions forum would be fine.

I can't guarantee I'll respond quickly though. As I mentioned, and as stated in the readme, modROS is unmaintained.

[SirNickelston]

I can't guarantee I'll respond quickly though. As I mentioned, and as stated in the readme, modROS is unmaintained.

Again, I cant strees enough how big of a help you are. Your litterally my last resort.

I have discovered my mistake, I had missed the device specific part of your previous explanation of ROS_IP. Do I understand correctly now that each machine has its own IP address on the network as ROS_IP? You said that I should consider the FS19+modROS as a separate machine. Do I need to pass a ROS_IP and ROS_MASTER_URI for this one as well?
With the revised settings, the environment variables in my setup now look like this:

guest(Ubuntu):

• Machine IP address: 192.168.2.207
• ROS_IP=192.168.2.207
• ROS_MASTER_URI=http://localhost:11311
• here is the roscore running

host(Windows):

• IP address of the machine: 192.168.2.189
• ROS_IP=192.168.2.189
• ROS_MASTER_URI=http://192.168.2.207:11311

(The IP addresses have changed because I am working from home today).
Unfortunately, still no data is shared from FS19. The self-written publisher, on the other hand, is still running. How could this actually run with "wrong" environment variables before?

One thing that might be important is that in all_in_one_publisher.py I had to change the string that specifies the save path to the mod (line 97), since the mod folder obtained from the repo is called FS19_modROS and not just modROS. Could this changed save path have an effect on the mod side?

[gavanderhoorn]

I have discovered my mistake, I had missed the device specific part of your previous explanation of ROS_IP. With the revised settings, the environment variables in my setup now look like this:

guest(Ubuntu):

* Machine IP address: `192.168.2.207`
* `ROS_IP=192.168.2.207`
* `ROS_MASTER_URI=http://localhost:11311`
* here is the roscore running

host(Windows):

* IP address of the machine: `192.168.2.189`
* `ROS_IP=192.168.2.189`
* `ROS_MASTER_URI=http://192.168.2.207:11311`

(The IP addresses have changed because I am working from home today).

This looks much more like what I would expect.

Do I understand correctly now that each machine has its own IP address on the network as ROS_IP?

yes, that's how it works.

ROS_IP is used by ROS nodes on one PC to tell other nodes on other PCs which IP address they should use to connect to them.

So it makes sense you'd set ROS_IP to the IP address of the machine on which you are setting the env variable, not to any IP of anything else (as those other machines would have their own value for ROS_IP).

You said that I should consider the FS19+modROS as a separate machine. Do I need to pass a ROS_IP and ROS_MASTER_URI for this one as well?

no.

What I meant was: the Windows PC on which you run FS19 (and modROS) needs to have ROS_IP and ROS_MASTER_URI set as well.
Sometimes people assume (for some reason) those variables are only used on Linux, or that the "ROS install" we use with modROS (ie: the pypi based one) is not a "real" ROS install (whatever that means).

I just wanted to clarify those values are really needed.

Unfortunately, still no data is shared from FS19. The self-written publisher, on the other hand, is still running.

hm, that's unfortunate indeed.

How could this actually run with "wrong" environment variables before?

I'm not sure.

One option could be you made a mistake configuring the env vars, but it's really just a possibility (ie: I'm not saying you made a mistake).

One thing that might be important is that in all_in_one_publisher.py I had to change the string that specifies the save path to the mod (line 97), since the mod folder obtained from the repo is called FS19_modROS and not just modROS. Could this changed save path have an effect on the mod side?

I'm not sure I understand what you mean by this.

I can't find any file which has a path on "line 97". Could you please link to it directly?

[gavanderhoorn]

@SirNickelston: did you get things to work in the end?

[SirNickelston]

Unfortunately not. I had to return the thesis topic. So now I will have to write my bachelor thesis on another topic.
In the institute where I work there is still a great interest in using your software package as a visualization tool. Therefore I will continue to work on the topic, now as a student assistant.

In the meantime, have you by any chance tried to run the currently provided version of the software on your hardware? Seeing if the bug can be replicated would certainly be of great use. Currently, I don't know how to find the issue.
The next thing I would try is a clean reinstall on another machine. This was not possible before due to the time frame of my work.

Do you have any other ideas or need any information?

Thanks again for your help ^^