Servers by jDrones

No connection when using mavproxy with jsbsim

linux
sitl
(Marcel Hohn) #1

I am facing the problem that running the sim_vehicle.py with the -f jsbsim option does not work. The problem has been described here:

According to the contributors, the issue should be fixed now. However, I am still facing the problem, despite of using the newest ardupilot code version.

Does anybody else have this problem? I would be very grateful for any help!

(Rajat Singhal) #2

Hi,
I just tried out the JSBSim simulation on my machine everything’s working properly. Closed it and again launched the simulation, still working

Are you using the latest JSBSim master? If not, please update it and try it again, there was a PR related to Ardupilot which was merged recently, that shouldn’t cause the problem but just in case.

Also, does the XTerm window show JSBSim starting correctly? There might be some error message about the connection from the JSBSim side also earlier

(Marcel Hohn) #3

Hi,

thank you for your super quick reply! I am using the latest version of the JSBSim master.

The XTerm window shows JSBSim starting correctly, I attached the XTerm output as a .txt file.

jsbsim_xterm.txt (12.1 KB)

In the terminal from which I started the sim_vehicle.py I get the following error message:

Connect tcp:127.0.0.1:5760 source_system=255
[Errno 111] Connection refused sleeping

The full command I used to start the simulation is:

sim_vehicle.py --map --console -f jsbsim --debug

(Rajat Singhal) #4

Well, the Xterm output seems clean, doesn’t seem to be any problem from that side.

Are you running this on Ubuntu 16.04 or something else?
Is the default SITL working correctly?
Please check this, after you close the sim_vehicle.py, check if the JSBSim process has been killed or not, you can use ps aux | grep JSBSim, there shouldn’t be anything else other than the grep process.

One last thing, wait for some 30secs to 1 min before again launching the simulation, the OS can take some time to free the ports. And also restart your system and try.

The main problem is that I’m not able to reproduce the error, that’s why need to do all this to see if anything can fix it

(Marcel Hohn) #5

I am using Ubuntu 18.04.

The default SITL (i.e sim_vehicle.py --map --console) works fine. The JSBSim process has been killed, I checked it with the provided command. Only the grep process appears then.

Also restarting the system did not work.

However, I noticed the following message in the xTerm output:

“Could not bind to socket for input …”

It does not appear in the same line each time I start the simulation, but it always appears. I think this is somehow the reason for the issue, some kind of connection problem between mavproxy and jsbsim…Also the terminal in which I started the sim_vehicle.py script gives the output:

Waiting for heartbeat from tcp:127.0.0.1:5760

(Rajat Singhal) #6

This is the problem, seems to be from the JSBSim side.
Is there any error message specifying the exact problem happening after this line?

You can also add the following code after this line, this will show any problem while connecting from the ardupilot side

Add this:

if (!sock_control.connect("!27.0.0.1", control_port)) {
    printf("Error while connecting to socket at 127.0.0.1:%u - Error: %s\n", 
                                             control_port, strerror(errno));
    return false;
}

Add it here also, change the variable name as needed

Sorry for all this, need to pinpoint the error. JSBSim works normally on 16.04, but might be that there are some problems on 18.04, if so then will need to create an issue on the JSBSim repo

(Rajat Singhal) #7

Just had an idea, can try out Ardupilot with JSBSim in a 18.04 Docker container, not sure if it will work or not
Do post if you get some new info or were able to figure out what’s going on, if there’s any specific workaround required then it can be added to the Wiki

(peterbarker) #8

ArduPilot master and

commit 3dcfda17fef0e58d077fcb9b24ee2cb9b68d3a95 (HEAD, JSBSim-Team/master)

are working for me today.

(Marcel Hohn) #9

Unfortunately, there is no error message on the ardupilot side, I just see mavroxy waiting for connection, indicated by the “MAV>” prompt.

There are also no further details in the error message. I also browsed the JSBSim source code I have on my machine and could not find the string “Could not bind to socket for input…” which is the error message I get from JSBSim. However, I found out, that this string was used in the file jsbsim/src/input_output/FGfdmSocket.cpp but was replaced in a commit from 10 Mar 2018 (see https://github.com/JSBSim-Team/jsbsim/commit/69e042b95c83e5be65af7d8f0ec3b511c9c51609#diff-c02dde2575d65a6176ca38e3b18556da). Is it possible that I am somehow running an old version of JSBSim? I went into the jsbsim directory and ran git log. It showed me that the last commits are from June 9, 2019 so I am really confused where this error message comes from…

(Marcel Hohn) #10

Maybe this helps, I used sockstat to see on which ports the programs are communicating with each other:

PROCESS PID PROTO SOURCE ADDRESS FOREIGN ADDRESS STATE
mavproxy.py 29975 tcp4 127.0.0.1:47872 127.0.0.1:5760 ESTABLISHED
arduplane 29979 udp4 *:5376 * : * CLOSED
arduplane 29979 udp4 127.0.0.1:44544 127.0.0.1:5503 ESTABLISHED
arduplane 29979 tcp4 127.0.0.1:42496 127.0.0.1:5505 ESTABLISHED
arduplane 29979 udp4 127.0.0.1:5376 * : * CLOSED
arduplane 29979 tcp4 *:5632 * : * LISTEN
arduplane 29979 tcp4 127.0.0.1:5632 127.0.0.1:47960 ESTABLISHED
arduplane 29979 tcp4 *:5632 * : * LISTEN
arduplane 29979 tcp4 *:5632 * : * LISTEN
JSBSim 29982 tcp4 *:5376 * : * LISTEN
JSBSim 29982 udp4 127.0.0.1:52480 127.0.0.1:5504 ESTABLISHED
JSBSim 29982 tcp4 127.0.0.1:5376 127.0.0.1:42612 ESTABLISHED

(Marcel Hohn) #11

Hello there, I am still not sure what exactly the problem was, but I fixed it so I think it might be worth sharing. It is really a special case, but however maybe it might help.

I don’t know how that happened, but I somehow had an executable of JSBSim in my /usr/games/ directory. This directory was also in the PATH variable, before the ~/jsbsim directory. So every time JSBSim was executed it was the one in /usr/games/ which apparently did not wórk. After deleting this executable everything works fine now.