Skip to content

Launching information as of 5/24/13

May 28, 2013

I am including this here for the record.

Frank asks:

Can you give me an overview of what the nodes/launchfiles needed to run granny are?

My response:

Look at the tierX_*.launch (where X is 1, 2, 3, and 4) launch files in the launch_files package. Those are how I launched most of the nodes. Here’s a diagram that is decently up to date on nodes and topics: https://www.lucidchart.com/documents/view/4e08-7a30-515ebe1f-a2c5-0f800a0057d0

But it doens’t include Sagar’s and your lane detection. Whatever you do with vision, the binary image topic that you publish needs to be in a parameter when you run log_polar_transform. I think the name is “subtopic” or something like that. That stuff goes in tier3_vision.launch. And by the way, the launch files do not include launching usb_cam_node. For whatever reason, whenever its launched from a launch file it publishes to a different topic than “usb_cam/image_raw” so I always had to launch it outside of the launch files. You could probably figure out why that happens and fix it. The diagram and the launch files also don’t include the javascript stuff. For that to work, you have to do:

1. rosrun rosbridge_server rosbridge.py (note: this is the new version of rosbridge, in the package rosbridge_server)
2. Open a browser and go to either
  a. localhost/DW if you opened the browser on doloras
  b. <DoloRAS’s URL>/DW if DoloRAS is connected to the web and you’re running the browser on another computer
  c. <IP address>/DW if doloras is broadcasting its own wifi network and you’re running the browser on another computer
3. Change the “ADDRESS” constant on line 16 of /var/www/DW/index.html to reflect what you’re doing (a, b, or c above)

To change goals, go into ReactiveDecisionMakers/nodes/GoalMaker.py and change the goals array. There are points that have units in meters. At the moment it just goes back and forth a ton, which I found to be useful to test.

Keep in mind that you will have to restart tier4_deciders.launch after each run. This restarts the GoalMaker (resetting the next goal) and the EKF (which may not be necessary if you’re using GPS updates, but might be a good idea to remove any accumulated error).

Lastly, I didn’t include vel_cmd_filter.py in the launch files because I used that as the “final switch” to actually start the robot moving. It’s the node that listens to the topic that javascript would publish to, so you can have everything up and running, and then finally start a run by rosrunning vel_cmd_filter. It doesn’t actually do any filtering, by the way. It used to, but it doesn’t anymore. You could instead get rid of it and have javascript publish directly to /vel_cmd, and then use PSoC_Velocities as the “final switch.”

Also, there are a couple tools I made for debugging and testing: tests_igvc scan_plotter.py and tests_igvc TopicUI.py. I mostly used scan_plotter to compare and calibrate scans, and quickly see if each sonar was working. TopicUI shows the last time a topic was being published to. I don’t think it would be too bad to have TopicUI always running in the background, but I always just ran it whenever I was debugging and killed it when I wasn’t using it. I never got around to making either of those parameter-based… which topics they subscribe to are in statically defined structures in the file.
Advertisements

From → Uncategorized

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: