FS-Driverless / Formula-Student-Driverless-Simulator

A virtual world where Autonomous Systems from different Formula Student teams can compete in time-trial challenges
https://fs-driverless.github.io/Formula-Student-Driverless-Simulator
GNU General Public License v2.0
202 stars 84 forks source link

ROS_Bridge issues #276

Closed kopebryant closed 2 years ago

kopebryant commented 2 years ago

Hi. I installed the latest version of the simulation on my windows pc and the rosbridge on my ubuntu laptop. When the system sends commands like throttle=0.2 the simulation always goes full throttle. I don't have this problem if everything is installed on the same ubuntu pc. Does anybody knows what causes this issue? I also have a problem with the ROS odometry topic. I know that there are older threads regarding this topic but I still wanted to know if anyone has updates or figured this out. When the simulations runs a few minutes and I reset the car to the starting position, the updated position is displayed on the odometry-ROS-topic up to 30 secs later.

wouter-heerwegh commented 2 years ago

Hi,

Just to get some more information about your setup, is the connection between 2 pc's wireless? If so, try to use ethernet cables instead. I noticed that it really makes a big difference in terms of delays. It is also best to run the bridge on the same device as the simulator itself. You can do this by installing WSL (make sure to not install WSL2, I never got it to work) and then running the bridge in there. You then will need to run the bridge with the UDP_control parameter set to true as documented here

I'm not so sure about the throttle though, I will try this out later.

kopebryant commented 2 years ago

Thanks for the quick reply. The windows pc and ubuntu laptop are both connected via lan. But the problem with the delay of the odometry topic happed on my other ubuntu setup in my university where everything is on the same pc.

wouter-heerwegh commented 2 years ago

Hi @kopebryant, I've just tried to create the same setup as you and I was not able to recreate this issue. When sending the control_command msg, could you check with rostopic echo /fsds/control_command that you are actually sending 0.2 as throttle?

For the 30sec delay, I was also not able to recreate this. Is the simulator lagging quite hard? Or not at all?

kopebryant commented 2 years ago

After I decreased the Max RPM of the car to e.g. 5000 in the Unreal Engine, it is working. I can now adjust the throttle to e.g 0.2 which is than also displayed in the simulation. But the delay is too high when I am sending the commands and images to a different pc. In the future I will only work on my Ubuntu setup.

For the 30sec delay, I was also not able to recreate this. Is the simulator lagging quite hard? Or not at all?

The simulation isn't lagging. If I visualize both the cone and car position or just print the car position via rostopic echo, the car position is updated with a huge delay.

wouter-heerwegh commented 2 years ago

But the delay is too high when I am sending the commands and images to a different pc. In the future I will only work on my Ubuntu setup.

I had this also in the beginning, but only when I was running both devices over WiFi, after I switched to ethernet for both, it was fine. If you are running both pc's over ethernet, could you check the delay to both devices by pinging? Did you also check that your laptop can handle all the processing?

To make sure it is not the connection, could you try running the bridge in windows and publish the ControlCommand.msg on ubuntu and echo the topic on both machines? If it arrives at the windows instance immediately, it's probably something with the simulator.

After I decreased the Max RPM of the car to e.g. 5000 in the Unreal Engine, it is working.

Is this with a custom car, or just the default one? It's quite strange that you had to change this.

kopebryant commented 2 years ago

I had this also in the beginning, but only when I was running both devices over WiFi, after I switched to ethernet for both, it was fine. If you are running both pc's over ethernet, could you check the delay to both devices by pinging? Did you also check that your laptop can handle all the processing?

The delay is very low (0.00072s). The laptop can handle this (Ryzen 7 and a GTX 1660 Ti).

To make sure it is not the connection, could you try running the bridge in windows and publish the ControlCommand.msg on ubuntu and echo the topic on both machines? If it arrives at the windows instance immediately, it's probably something with the simulator.

I tried running the bridge on windows via wsl. Unfortunetly my laptop cannot communicate with it due to firewall issues. I cant even ping wsl. I tried to make a new rule for it to open the Port 11311 but there is currently a bug in Windows 11 that doesnt allow me add a new rule. I think that the firewall or Windows 11 in general may cause the delay issues. But this wouldnt explain the delays with the odometry because this issue is on my setup where everything is installed on the the ubuntu PC.

Is this with a custom car, or just the default one? It's quite strange that you had to change this. Its the default technion car. I only change the maxrpm in the vehiclemovement file inside the TechnionCarPawn file

wouter-heerwegh commented 2 years ago

I'll to replicate the delay and the issue with the ControlCommand.msg in Ubuntu later today or tomorrow. Do you use Ubuntu 20.04 or 18.04 or something older? Also, which ROS version?

Could you also send me your settings file? This way our setup is more similar.

kopebryant commented 2 years ago

I use Ubuntu 18.04 with ROS Melodic. I changed the z-value in settings.json because our slamalgorithm didnt worked well if the the nose of the car or anything else static is in the image.

{ "SeeDocsAt": "https://FS-Driverless.github.io/Formula-Student-Driverless-Simulator/", "SettingsVersion": 1.2, "ViewMode": "SpringArmChase", "ClockSpeed": 1.0, "SpectatorServerPassword": "password", "PawnPaths": { "DefaultCar": { "PawnBP": "Class'/AirSim/VehicleAdv/Cars/TechnionCar/TechnionCarPawn.TechnionCarPawn_C'" } }, "Vehicles": { "FSCar": { "DefaultVehicleState": "", "EnableCollisionPassthrogh": false, "EnableCollisions": true, "AllowAPIAlways": true, "RC":{ "RemoteControlID": -1 }, "Sensors": { "Imu" : { "SensorType": 2, "Enabled": true }, "Gps" : { "SensorType": 3, "Enabled": true }, "Lidar1": { "SensorType": 6, "Enabled": true, "X": 0.45, "Y": 0, "Z": 0.55, "Roll": 0, "Pitch": 0, "Yaw" : 0, "NumberOfLasers": 4, "PointsPerScan": 4096, "VerticalFOVUpper": 5, "VerticalFOVLower": -5, "HorizontalFOVStart": -90, "HorizontalFOVEnd": 90, "RotationsPerSecond": 10, "DrawDebugPoints": false }, "Lidar2": { "SensorType": 6, "Enabled": true, "X": 1.20, "Y": 0, "Z": 0.2, "Roll": 0, "Pitch": 0, "Yaw" : 0, "NumberOfLasers": 4, "PointsPerScan": 4096, "VerticalFOVUpper": 5, "VerticalFOVLower": -5, "HorizontalFOVStart": -90, "HorizontalFOVEnd": 90, "RotationsPerSecond": 5, "DrawDebugPoints": false }, "GSS" : { "SensorType": 7, "Enabled": true } }, "Cameras": { "cam1": { "CaptureSettings": [ { "ImageType": 0, "Width": 640, "Height": 480, "FOV_Degrees": 90 } ], "X": -0.3, "Y": -0.16, "Z": 1.35, "Pitch": 0.0, "Roll": 0.0, "Yaw": 0 }, "cam2": { "CaptureSettings": [ { "ImageType": 0, "Width": 640, "Height": 480, "FOV_Degrees": 90 } ], "X": -0.3, "Y": 0.16, "Z": 1.35, "Pitch": 0.0, "Roll": 0.0, "Yaw": 0.0 } }, "X": 2, "Y": 0, "Z": 0, "Pitch": 0, "Roll": 0, "Yaw": 0 } }, "SubWindows": [ ] }

wouter-heerwegh commented 2 years ago

Hi @kopebryant

I've run the same settings as you on Ubuntu 18.04 with ROS Melodic and I can't replicate your problem. Could you run the simulator only (no other algorithms), move the car and call rosservice call /fsds/reset "waitOnLastTask: false".

Does it still take as long?

kopebryant commented 2 years ago

The Problem is definitely my algorithm. It seems that it buffers old data and doesn't use the new car position. If nothing runs in the background than the car position refreshes immediately in the rostopic.  Thank you very much for your help and patience.

wouter-heerwegh commented 2 years ago

Hi @kopebryant

Great that you were able to find the problem. If you keep processing old data, you could try to make the queue size of the subscriber, that is handling the position of the car, smaller (for instance 1).

Hope that helps!