Capstone project simulator ignores or doesn't receive commands

[fantauzzi]

I am sending throttle commands over /vehicle/throttle_cmd at a rate of 50Hz, each of them directing the simulator to apply a throttle of 1.0. The simulator randomly ignores around 60% of those commands: it applies a throttle of 1.0 around 40% of the times, and a throttle of 0.0 the rest of the times, as reported over /vehicle/throttle_report.

As a result, the car doesn't accelerate at the rate it should, but much slower, and to maintain constant speed I have to send a throttle of 1.0 almost continuously. Even worse, it is practically impossible to properly tune a PID controller.

It might be that styx/bridge.py discards some of the messages and doesn't forward them to the simulator.

I am reproducing the issue in an almost systematic way on a "native" Ubuntu 16.04. During some runs the issue doesn't happen.

Two other students have reported what looks like the same issue in the Forums, see https://discussions.udacity.com/t/simulator-communication-bug-with-styx-bridge-py/397867

I have observed the same for different fixed throttle values (e.g. .1 and .5) and different updates frequency in the DBW node (30, 50 and 100 Hz).

I am providing a minimal amount of code that reproduces the issue, you can clone it from https://github.com/fantauzzi/CarND-Capstone-issue

From the starter code, I have added one line to dbw_node.py, and a little more to report the diagnostic, that goes into the dbw_node-?-stdout.log log file. Check the log file after running the program with the simulator for a couple of seconds.

[fantauzzi]

This is what I am sending the simulator, throttle commands to set the throttle to 1.0 at 50Hz:

-> rostopic echo /vehicle/throttle_cmd
pedal_cmd: 1.0
pedal_cmd_type: 2
enable: True
clear: False
ignore: False
count: 0
---
pedal_cmd: 1.0
pedal_cmd_type: 2
enable: True
clear: False
ignore: False
count: 0
---
pedal_cmd: 1.0
pedal_cmd_type: 2
enable: True
clear: False
ignore: False
count: 0
---
pedal_cmd: 1.0
pedal_cmd_type: 2
enable: True
clear: False
ignore: False
count: 0
---
pedal_cmd: 1.0
pedal_cmd_type: 2
enable: True
clear: False
ignore: False
count: 0
---
pedal_cmd: 1.0
pedal_cmd_type: 2
enable: True
clear: False
ignore: False
count: 0

and this is the throttle the simulator is applying, 1.0 some times, 0.0 most of the times:

-> rostopic echo /vehicle/throttle_report
data: 1.0
---
data: 1.0
---
data: 1.0
---
data: 0.0
---
data: 0.0
---
data: 0.0
---
data: 0.0
---
data: 0.0
---
data: 0.0
---
data: 1.0
---
data: 1.0
---
data: 1.0
---
data: 1.0
---
data: 0.0
---
data: 1.0
---
data: 1.0
---
data: 1.0
---
data: 1.0
---
data: 1.0
---
data: 0.0
---
data: 0.0
---
data: 0.0
---
data: 0.0
---
data: 0.0

[baumanab]

Thank you for reporting this. The team is aware of it and we are looking into it.

[boxmein]

Running the simulator natively, but ROS in a VM, on a 2016 Macbook Pro. The simulator does have SLIGHT lag, but not too much. Here's a sample of my ROS logs for the last three minutes the car has stood still:

(current velocity & steering are from the /current_velocity endpoint, cmd_vel and cmd_steer from the /steering_cmd and /velocity_cmd endpoint, and accel and steer are my controller's control values)

[JacquesRoth]

I believe I am seeing the same problem. Cannot achieve more than 35 MPH or so even at full throttle and acceleration slow. I am running under Windows Home 10, VirtualBox, robov2.1.0 VM, 6 core 3 Ghz CPU, AMD Radeon card, no Nvidia GPU. Tried changing queue sizes for publishers and subscribers to 5 in bridge.py, did not seem to help.

[MichaelX99]

I to am having this problem, it is impossible to move forward on any code besides the tl detector since all motion relys on having a strong connection with the simulator.

[JacquesRoth]

I put a lot of debug code into the bridge.py and server.py scripts. It appears to me the simulator is totally at fault, it looks like the simulator sometimes ignores throttle messages and reports the throttle is set to 0, even though 1 has been commanded for a long time.

[tjacobs]

Yeah, it's something in the simulator, I'm having the same problem. Something to do with receiving the messages from the websocket. Perhaps try reproducing on a slower MacBook Air 2012. Perhaps running the simulator in Unity rather than standalone will let us see where the issue lies.

[pierluigiferrari]

@baumanab any news on this? I'm seeing the same problem, but it's even more problematic when trying to brake: Even if I publish a constant stream of ridiculously large braking torque values (like 20,000 Nm or more) to /vehicle/brake_cmd, the car still doesn't slow down even remotely fast enough. It actually feels as if the car was just coasting, not actively braking at all. Echoing /vehicle/brake_report reveals that the simulator seems to be ignoring the majority of the braking values I publish, identically to what @fantauzzi reported above (but with braking values).

At this point I don't know how I'm supposed to get the car to stop in time at a red light, which is a blocker for my team and I because we're pretty much done otherwise.

I'm running Ubuntu 16.04 natively on a powerful machine.

[JacquesRoth]

In my system, the car very infrequently does not brake properly and I think it is the same problem.

----- Original Message -----

From: "Pierluigi Ferrari" notifications@github.com To: "udacity/sdc-issue-reports" sdc-issue-reports@noreply.github.com Cc: "jacquesroth" JacquesRoth@comcast.net, "Comment" comment@noreply.github.com Sent: Tuesday, November 28, 2017 2:06:32 PM Subject: Re: [udacity/sdc-issue-reports] Capstone project simulator ignores or doesn't receive commands (#1217)

@baumanab any news on this? I'm seeing the same problem, but it's even more problematic when trying to brake: Even if I publish a constant stream of ridiculously large braking torque values (like 20,000 Nm or more) to /vehicle/brake_cmd , the car still doesn't slow down even remotely fast enough. It actually feels as if the car was just coasting, not actively braking at all. Echoing /vehicle/brake_report reveals that the simulator seems to be ignoring the majority of the braking values I publish.

At this point I don't know how I'm supposed to get the car to stop in time at a red light, which is a blocker for my team and I because we're pretty much done otherwise.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub , or mute the thread .

[pierluigiferrari]

With me it's not an occasional thing, the car never brakes as it should if you send very large torque values to the simulator.

[JacquesRoth]

On her system, one of my teammates reports that when /final_waypoints was sent by the waypoint_updater at each callback received in pose_cb, the car would not even move. She got the car moving by not sending the /final_waypoints message on every call, maybe only once every 2 or 3 calls. Perhaps a clue that the simulator can be overloaded by messages or it could be an additional issue.

This needs to be fixed or many groups will not be able to finish the project.

[baumanab]

Thanks for all the updates and sorry I haven't been as responsive. I spoke to some team members and we are trying to figure out what is going on. It could be multiple causes producing similar outcomes. I'm wondering if latency is responsible for a large proportion of the outcome.

[JacquesRoth]

I think latency is involved, perhaps causing some race condition in the simulator. However, I doubt it is latency external to the simulator, as I see consistent full throttle messages sent and the car not speeding up.

[macd]

I too am seeing this same problem. Simulator running on native Ubuntu 16.04 while ROS is running in a VM. Additionally, if I am lucky enough to make it around the track with constant throttle commands and steering controlled by the yaw_controller, I find discontinuous jumps in the car's location as returned by the simulator. In fact, the car only moves in discontinuous jumps. It sits for 10 call backs or so and then jumps by lot. Here is an example where I have printed out x, y, next waypoint index. Should I file an additional issue?

894.820900,1129.014000,10900 895.236800,1129.007000,10901 895.236800,1129.007000,10901 895.445900,1129.004000,10901 895.867200,1128.998000,10901 895.867200,1128.998000,10901 896.289800,1128.992000,10901 896.289800,1128.992000,10901 910.596700,1128.805000,13 910.596700,1128.805000,13 910.596700,1128.805000,13 910.596700,1128.805000,13 910.596700,1128.805000,13 910.596700,1128.805000,13 910.596700,1128.805000,13 910.596700,1128.805000,13 913.065600,1128.782000,21 913.065600,1128.782000,21 913.065600,1128.782000,21 913.065600,1128.782000,21 913.065600,1128.782000,21 913.065600,1128.782000,21 913.065600,1128.782000,21 913.065600,1128.782000,21 913.065600,1128.782000,21 913.065600,1128.782000,21 913.065600,1128.782000,21 913.065600,1128.782000,21 914.879200,1128.768000,26

[JacquesRoth]

Myself and another of my teammates report that changing the rate in dbw_node.py from 50 to 10 made a big improvement. Unfortunately, 50 is required for Carla. Hope this is a clue.

[swwelch]

Hi all, just wanted to update here. For @fantauzzi's issue, this is caused by control commands not persisting in the simulator. Throttle commands may be sent to the simulator, but that variable in the simulator might be 0 when /throttle_report is sent back. This works slightly differently in the actual vehicle (as it takes some time for the throttle to return to 0). We will release a new version of the simulator that has the latest received control commands displayed. For now, I wouldn't trust data coming back from /throttle_report.

Additionally, it seems like many of the problems described above are due to the large amounts of data being sent between the simulator and ROS on VM. As a short term solution, we believe that this will be fixed by enabling toggling of the image data from the simulator. We have tested a version of the simulator that is not sending image data, and it runs well on a Macbook Air with ROS in a VM. We should be able to release this version of the simulator shortly!

[pierluigiferrari]

@swwelch thanks for the update!

In my case though, I'm not using a VM, I run Ubuntu 16.04 natively and still have this problem. Even if we ignore the throttle/braking report data for now, I still see the phenomenon that the car doesn't slow down even remotely fast enough despite my dbw_node publishing a steady stream of very large braking torque values of 20,000 Nm or more. So this might not only be a VM-related issue.

[JacquesRoth]

I believe students are supposed to use the image sent by the simulator to determine the state of the traffic lights, so they will not be able to complete the project if the image data must be turned off. The simulator does publish the traffic light state, but as I understand it, it is only supposed to be used to debug. Perhaps the project requirement could be relaxed so that the published traffic light state can be used for the simulator.

[swwelch]

@pierluigiferrari, thanks for the additional info. It's possible that there is some queuing/latency problem with so much data over websockets (which is fixed when turning off images), but we are having a hard time duplicating this natively in Ubuntu. Any idea what deceleration you are observing from the car in m/s^2? I think you can read this from the AccT value displayed in the simulator. The Dataspeed DBW code will limit accel/decel to 9.8m/s^2 (1 g).

[macd]

This continues to be a huge issue for me as well. I have written a script that does a running total of the valid throttle commands as returned by the rostopic echo command. I print out a running total percentage correct as well as a percentage correct for the last 100 samples (2 seconds) (script is in github.com/macd/CarND-Capstone/scripts ) There are periods for up to 10 seconds where the throttle command is zero, (snippit from log below). These are correct, since the car slows to a stop and steering becomes totally borked.

My setup is Ubuntu 16.04 native for simulator on a 3 year old Lenovo Y50 and ros runs in the Udacity provided VM

How can I turn off images to verify that this is the problem?

... total 0.167304 period 0.170000 total 0.167341 period 0.190000 total 0.167443 period 0.230000 total 0.167252 period 0.050000 total 0.167321 period 0.210000 total 0.167050 period 0.000000 total 0.166780 period 0.000000 total 0.166511 period 0.000000 total 0.166242 period 0.000000 total 0.165974 period 0.000000 total 0.165707 period 0.000000 total 0.165441 period 0.000000 total 0.165176 period 0.000000 total 0.165024 period 0.070000 ...

On Thu, Dec 7, 2017 at 11:10 AM, Stephen Welch notifications@github.com wrote:

@pierluigiferrari https://github.com/pierluigiferrari, thanks for the additional info. It's possible that there is some queuing/latency problem with so much data over websockets (which is fixed when turning off images), but we are having a hard time duplicating this natively in Ubuntu. Any idea what deceleration you are observing from the car in m/s^2? I think you can read this from the AccT value displayed in the simulator. The Dataspeed DBW code will limit accel/decel to 9.8m/s^2 (1 g).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/udacity/sdc-issue-reports/issues/1217#issuecomment-350065029, or mute the thread https://github.com/notifications/unsubscribe-auth/AAahxh2eFN3Jjz5YhB59OrRAkfJBzg9aks5s-Dg8gaJpZM4Qaw7y .

[swwelch]

Ok, we've just release a new version of the simulator here that we think will fix all these problems! Please download it and let us know if you are still seeing any of these issues.

[JacquesRoth]

The speed issue is no longer present on my system. However, the new simulator does not seem to work with some of the traffic lights, the first one for sure, I suspect it is reporting their states incorrectly. Running exactly the same code with the older simulator works with the traffic light data reported by the simulator.

[JacquesRoth]

Found the problem. Must check mark the camera box or no image messages whatsoever are received and my code was dependent on being called even though I was not processing the image in this version of my code.

[macd]

OK this fixes my issues as well.

So there is a new track added to this version of the simulator, ie the Test Lot. Are there waypoints and a launch file that we can use to run on this track?

On Thu, Dec 7, 2017 at 11:24 PM, JacquesRoth notifications@github.com wrote:

Found the problem. Must check mark the camera box or no image messages whatsoever are received and my code was dependent on being called even though I was not processing the image in this version of my code.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/udacity/sdc-issue-reports/issues/1217#issuecomment-350192645, or mute the thread https://github.com/notifications/unsubscribe-auth/AAahxqFEe_eFB7epFXwDXid8rn2oqu6qks5s-OQigaJpZM4Qaw7y .

[swwelch]

@macd In the CarND-Capstone/data folder there is a churchlot_with_cars.csv that has waypoints you can use. You'll need to use them in the CarND-Capstone/ros/src/waypoint_loader/launch/waypoint_loader.launch launch file and set the velocity param value to something small, like 10 (kph).

[macd]

Great! Many thanks.

On Fri, Dec 8, 2017 at 11:30 AM, Stephen Welch notifications@github.com wrote:

@macd https://github.com/macd In the CarND-Capstone/data folder there is a churchlot_with_cars.csv that has waypoints you can use. You'll need to use them in the CarND-Capstone/ros/src/waypoint_loader/launch/ waypoint_loader.launch launch file and set the velocity param value to something small, like 10 (kph).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/udacity/sdc-issue-reports/issues/1217#issuecomment-350351154, or mute the thread https://github.com/notifications/unsubscribe-auth/AAahxr065zZvrWqTrMt1eXiCEg38g7Gjks5s-Y4-gaJpZM4Qaw7y .

[baumanab]

Time will tell, but so far it sounds like the original issue is resolved. If anyone on this thread who tests the new simulator has suggestions for helpful release notes, please let us know. We can add notes to the release page.

[JacquesRoth]

Make sure to mention exactly what the Camera check box does.

----- Original Message -----

From: "Andrew Bauman" notifications@github.com To: "udacity/sdc-issue-reports" sdc-issue-reports@noreply.github.com Cc: "jacquesroth" JacquesRoth@comcast.net, "Comment" comment@noreply.github.com Sent: Friday, December 8, 2017 12:18:58 PM Subject: Re: [udacity/sdc-issue-reports] Capstone project simulator ignores or doesn't receive commands (#1217)

Time will tell, but so far it sounds like this original issue is resolved. If anyone on this thread who tests the new simulator has suggestions for helpful release notes, please let us know. We can add notes to the release page.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub , or mute the thread .

[macd]

So now we have another problem. When the camera is turned on, the steering angle is not always updated. Sometimes it gets stuck at a certain value. This makes it difficult to stay in lane sometimes and I am lucky to make it around the track once. With the camera turned off, I ran for 14 hours straight.

On Fri, Dec 8, 2017 at 1:12 PM, JacquesRoth notifications@github.com wrote:

Make sure to mention exactly what the Camera check box does.

----- Original Message -----

From: "Andrew Bauman" notifications@github.com To: "udacity/sdc-issue-reports" sdc-issue-reports@noreply.github.com Cc: "jacquesroth" JacquesRoth@comcast.net, "Comment" < comment@noreply.github.com> Sent: Friday, December 8, 2017 12:18:58 PM Subject: Re: [udacity/sdc-issue-reports] Capstone project simulator ignores or doesn't receive commands (#1217)

Time will tell, but so far it sounds like this original issue is resolved. If anyone on this thread who tests the new simulator has suggestions for helpful release notes, please let us know. We can add notes to the release page.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub , or mute the thread .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/udacity/sdc-issue-reports/issues/1217#issuecomment-350373263, or mute the thread https://github.com/notifications/unsubscribe-auth/AAahxmGZ7cOxVFh9tMBYyxi1v0bxVx-0ks5s-aZSgaJpZM4Qaw7y .

[macd]

Update:

Here is a hack around the simulator issues dropping either throttle values (version v1.2 of the simulator) or dropping steering (version v1.3 of the simulator) if you are lucky enough to have two Linux computers to use. (I also have the router connecting them in the same room) You run the simulator on a separate computer from the ROS VM and then do port forwarding.

There are two easy steps to this. First, for the VM in Network tab of Settings, set "attached to" : "Bridged Adapter". This will allow the VM to get its own IP address. Reboot the VM and note its IP address (using ifconfig, for example). For me, I got 192.168.1.14.

Second, on the machine you are going to run the simulator, open a separate window and issue this command (replace with correct IP)

ssh -nNT -L *:4567:localhost:4567 student@192.168.1.14

You will then be asked for your student password. This routes localhost:4567 to localhost:4567 on the remote (ie 192.168.1.14)

That's it. Fire up the sim and roslaunch and should be good to go.

On Sun, Dec 10, 2017 at 12:04 AM, Don MacMillen don@macmillen.net wrote:

So now we have another problem. When the camera is turned on, the steering angle is not always updated. Sometimes it gets stuck at a certain value. This makes it difficult to stay in lane sometimes and I am lucky to make it around the track once. With the camera turned off, I ran for 14 hours straight.

On Fri, Dec 8, 2017 at 1:12 PM, JacquesRoth notifications@github.com wrote:

Make sure to mention exactly what the Camera check box does.

----- Original Message -----

From: "Andrew Bauman" notifications@github.com To: "udacity/sdc-issue-reports" sdc-issue-reports@noreply.github.com Cc: "jacquesroth" JacquesRoth@comcast.net, "Comment" < comment@noreply.github.com> Sent: Friday, December 8, 2017 12:18:58 PM Subject: Re: [udacity/sdc-issue-reports] Capstone project simulator ignores or doesn't receive commands (#1217)

Time will tell, but so far it sounds like this original issue is resolved. If anyone on this thread who tests the new simulator has suggestions for helpful release notes, please let us know. We can add notes to the release page.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub , or mute the thread .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/udacity/sdc-issue-reports/issues/1217#issuecomment-350373263, or mute the thread https://github.com/notifications/unsubscribe-auth/AAahxmGZ7cOxVFh9tMBYyxi1v0bxVx-0ks5s-aZSgaJpZM4Qaw7y .

[JacquesRoth]

Most of us are not that lucky, I do not even have one! People are going to fail this project if the simulator is not fixed.

[swwelch]

With the camera images on, the data flowing over websockets is more than most machines can handle, which is what is causing the behavior @macd is seeing. We've provided the option to develop without camera images to enable all teams to get the car running around the track, but I'm not sure there is much more we will be able to do immediately.

New code has been merged to the final project to do some monkey patching in the Python server, and this might help for some users. I'd like to close this waffle bug since the original issue has been resolved, but please feel free to open new issues!

[CodingCanuck]

If too many images is the problem, could the simulator publish camera images at a reduced frequency rather than turning them off entirely?

[macd]

OK, Jacques' one computer issue made me think a little deeper on the issue.

The fact that my two computer solution was working is not due to two computers, it is simply that we are using the router's memory to buffer the images from the simulator.

So we can do this on one computer by essentially following my previous instructions, but it requires two things

1) ROS must be run inside the VM

2) You must be able to do port forwarding. I know how to do this on Linux but have no clue about Windows or Mac.

The procedure is as before: 1) Set networking to bridging. Reboot VM and get it's IP address. (see instructions in previous email) 2) (For Linux host) On the host open a terminal window and type the port forwarding command: (replace the IP address with the one obtained from step 1) ssh -nNT -L *:4567:localhost:4567 student@192.168.1.14

Now proceed as normal.

I have this setup running on my laptop and it looks good. The car is into its third lap with no problems.

Udacity guys... you can help a lot of people by figuring out how to do port forwarding on Windows and Mac.

I hope this can help some folks!

On Mon, Dec 11, 2017 at 1:04 PM, CodingCanuck notifications@github.com wrote:

If too many images is the problem, could the simulator publish camera images at a reduced frequency rather than turning them off entirely?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/udacity/sdc-issue-reports/issues/1217#issuecomment-350857628, or mute the thread https://github.com/notifications/unsubscribe-auth/AAahxjmKO1BrrNk5HLFheMfCVwuAHAN6ks5s_ZjXgaJpZM4Qaw7y .

[JacquesRoth]

I am already using port forwarding on my Windows system, ROS runs in the VM. I have not seen any more speed control problems on the new simulator. I am not sure I am seeing the steering problem on the new simulator, the car stays in the lane but seems to be swerving a lot.

[macd]

I think, if you look closely, the swerving is caused by the steering angle not being updated. The port forwarding trick only works if you have bridged the network connection on the VM, which causes the connection to go through the router.

I do believe that the two computer solution is more robust however. With it I recorded 76 laps without incident before I terminated the simulation. With the single computer + VM bridged + port forwarding, the car crashed after 23 laps, but the driving behavior was much less 'swervy' than the initial setup.

On Tue, Dec 12, 2017 at 12:20 PM, JacquesRoth notifications@github.com wrote:

I am already using port forwarding on my Windows system, ROS runs in the VM. I have not seen any more speed control problems on the new simulator. I am not sure I am seeing the steering problem on the new simulator, the car stays in the lane but seems to be swerving a lot.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/udacity/sdc-issue-reports/issues/1217#issuecomment-351181837, or mute the thread https://github.com/notifications/unsubscribe-auth/AAahxiVMpvywu_2RKeBf8521f8T7TcQ0ks5s_t_8gaJpZM4Qaw7y .

[marlon-rodrigues]

Hey @macd, thanks for the details on the port forwarding. I'm trying to follow along but after updating the VM to use network bridging, when I run roslaunch, I get a "too many packages to unpack" error. Did you get that as well? If so, how did you get around it?

Thanks!

[macd]

Hey @marlon-rodrigues The networking issues should be completely orthogonal to using roslaunch, but to answer your question directly, no I did not get any errors like this.

The "too many values to unpack" is a typical Python error when you return more elements from a function than the caller expects. It says the traceback was written to the logfile, you should look there, or alternatively...

I usually use the -v option with roslaunch so it writes all those errors out to the terminal. I make so many errors, this turns out to be a real time saver for me.

Hope this helps!

On Wed, Dec 13, 2017 at 11:53 AM, Marlon Geraldo Rodrigues Viana < notifications@github.com> wrote:

Hey @macd https://github.com/macd, thanks for the details on the port forwarding. I'm trying to follow along but after updating the VM to use network bridging, when I run roslaunch, I get a "too many packages to unpack" error. Did you get that as well? If so, how did you get around it? [image: image] https://user-images.githubusercontent.com/9003638/33959386-33199b78-e03f-11e7-8df5-4c8540f69a38.png

Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/udacity/sdc-issue-reports/issues/1217#issuecomment-351503330, or mute the thread https://github.com/notifications/unsubscribe-auth/AAahxtc18WuXk8_Osu7SeSI6C_C1WUFpks5tACtGgaJpZM4Qaw7y .

[marlon-rodrigues]

Thanks @macd! That definitely helps. It seems like the parse_http_host_and_port function within ros' own launch file is returning more values than expected. I will try to check what's happening there. Thanks again!

[JacquesRoth]

I am not an expert on this stuff, but I have been looking at all these ROS messages and it seems to me sending the images as ROS messages is incurring massive overhead and some other mechanism should really be used. If the images were just transferred in some kind of shared memory queue I think the problems would go away. As it is, messages are constructed with all the ROS headers, serialized into little packets, port forwarded if a VM is involved, reassembled, decoded, etc. Surprised it works on any machine.

[JacquesRoth]

I created a new virtual machine with more disk space and I forgot to configure port forwarding. Even running the new simulator, I had extreme issues with the car speed, could not go more than 2 MPH or so. Turned on port forwarding and the speed problem went away. So definitely, if using a VM, do port forwarding!

[marlon-rodrigues]

Agreed @JacquesRoth, I had someone on my team trying to run both the simulator and ros on the VM. Needless to say he had a hard time with it and had to switch to port forwarding.

[marlon-rodrigues]

@macd FYI, I was able to solve my problem my hardcoding the VM's IP address into my ros launch.py and network.py (server_uri and os.environ[ROS_IP] variables respectively). The IP generated by the VM had a bunch of trailing numbers that were messing up with ros' initializer. I can only assume that it happened because both my machines are Macs. Anyways, was able to drive the car with both waypoints and camera data running without any issues. Thanks again for the tip.

[macd]

@marlon-rodrigues good to know that you were able to debug the problem!

On Thu, Dec 14, 2017 at 12:10 PM, Marlon Geraldo Rodrigues Viana < notifications@github.com> wrote:

@macd https://github.com/macd FYI, I was able to solve my problem my hardcoding the VM's IP address into my ros launch.py and network.py (server_uri and os.environ[ROS_IP] variables respectively). The IP generated by the VM had a bunch of trailing numbers that were messing up with ros' initializer. I can only assume that it happened because both my machines are Macs. Anyways, was able to drive the car with both waypoints and camera data running without any issues. Thanks again for the tip.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/udacity/sdc-issue-reports/issues/1217#issuecomment-351822401, or mute the thread https://github.com/notifications/unsubscribe-auth/AAahxhV-OgxnQ0Bka8RZG761EX4R9hBDks5tAYC2gaJpZM4Qaw7y .

[JacquesRoth]

This is a major issue still. One of the team members assigned to the PID controller is trying to adjust the yaw rate controller but cannot because the camera images are overloading her VM system and cannot be turned off in the old simulator. The new simulator has steering problems regardless of whether the camera is on or off. So we have no solution and the project is just about due.

What can be done to help us?

[srikanth-narayanan]

Has any one come up with a solution yet. With to without camera, It is impossible to tune the PID controller. Has any one achieved it. My car always has steering problems. Please help us

[macd]

Do as much as you can with the camera turned off. Should be able to tune PID controllers for the throttle that way. Udacity supplied steering control works OK but can be made better. When you need to test braking, pick an arbitrary waypoint and pretend it is a red light, still with the camera turned off. You will need to tune the max braking (needs to be much larger than default) to ensure you stay within accel and jerk limits. Wish I could suggest more but the simulator / ROS combo with the camera turned on is a real pig and is swamping some system resource.

On Thu, Jan 11, 2018 at 12:51 AM, Srikanth Narayanan < notifications@github.com> wrote:

Has any one come up with a solution yet. With to without camera, It is impossible to tune the PID controller. Has any one achieved it. My car always has steering problems. Please help us

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/udacity/sdc-issue-reports/issues/1217#issuecomment-356866694, or mute the thread https://github.com/notifications/unsubscribe-auth/AAahxlsMwfBgjJgXqh2Cda52cf6KZVQ_ks5tJct9gaJpZM4Qaw7y .

[JacquesRoth]

Our group got it working with and without camera on in the new simulator. Make sure you have port forwarding on if you are using VM's. Make sure your braking force is a NON-NEGATIVE number and can get to the maximum of around 18000 using whatever your P in the PID constant is. Steering was never quite perfect with the version 2 simulator at 50 MPH but we managed to get it to stay in lane.

[1R053]

@marlon-rodrigues I had the error "too many values to unpack" when running roslaunch as well. Reason: Parallels was assigning IPv4 and IPv6 addresses. The latter is confusing roslaunch.

Solution: disable IPv6 for Parallels

sudo nano /Library/Preferences/Parallels/network.desktop.xml
<IPv6Enabled>0</IPv6Enabled>

[sjoshi30]

@macd I am trying to run simulator in Windows and Capstone Project in Linux laptop but though they are on same network the styx node is terminated due to no connectivity. What am I doing wrong? Any other network changes to be made ? Please guide on this. Thanks!