uofa-spear / software Goto Github PK

Or at least consistent with what has been given to controller_manager...

We don't actually need docker toolbox because we're running everything in a virtualbox VM.

Right now, udp.launch (which connects to the base station) does not run in the simulator. It might be useful to run it (or at least have a flag for that) to test diagnostics and so on.

Right now I'm pretty sure the costmaps are in some kind of legacy mode where they automatically load certain layers. We might want to manually configure these layers ourselves since this gives us better control over things. For example, we could make the global costmap not have an obstacle layer (though this may be possible right now anyway).

The topics need to be the same in the simulator and in the real world. The fact that they are not will currently break e.g. the navigation code, which expects camera images from a certain topic. Might also be nice to define some kind of convention for odometry and so on from different sources.

Currently in unpack.sh and potentially other scripts, we use && to ensure that the script exits with an error if a command exit with an error. We don't need to do this if we use set -e

Environment variables can be set in launch files, but the gazebo ones are currrently being set in unpack.sh. It would probably be cleaner to define them within the simulator launch files.

just creating this issue to mess around with project management

We would like to have an easy way to bring up an rviz window that shows visualizations related to the nav stack such as the global and local plans, costmaps, point clouds, etc.

This will help us quickly diagnose nav stack issues.

This can probably just be done by creating a saved rviz configuration. See this:
https://answers.ros.org/question/11845/rviz-configuration-file-format/

e.g. launch file changes, using rviz, etc.

We are already running the camera feed and joystick controls through the nimbro network udp_sender. It would be nice to send all the ros topics we need through either udp_sender or tcp_sender since these should have less overhead than the standard ros topic transport and they are more configurable.

@rpshukla said that this was because something was missing from my .bashrc.

This should be added to unpack.sh I believe.

We would like to run ROS inside a docker container on both the base station computer and the rover computer. To do this, we need to be able to manually assign a static ip to both docker containers. Also, each docker container needs to be able to connect to the host computer's network.

We'll need to figure out how to configure networking in docker and write instructions on how to set it up on one's own computer.

These instructions should go in the main README.

Check what communications are being run through udp_sender. We need something like

• camera feed (probably done already but names changed)
• drive commands
• diagnostics (right now all under /web)
• FlexBE commands (probably all under /flexbe)

It's in master and is making this test fail for every new branch. Does anyone know why this file is here anyway? As far as I can tell nothing uses it. The closest is in arm.py which has

from kivy.garden.knob import Knob

which is probably not actually importing knob.py unless someone messed around with __init__.py or something.

Just putting this here because I was looking at it recently and need to put it somewhere visible.

We won't be getting GPS integrated into CAN bus this year, but we can just plug it straight into the TX2 and use this node: http://wiki.ros.org/nmea_navsat_driver.

For integrating it into our localization data: http://docs.ros.org/melodic/api/robot_localization/html/integrating_gps.html

We had this working last year using gstreamer. Since a lot of the code changed this year we need to make sure this still works.

If the simulator is run in a VM (whether in docker or not), gazebo immediately crashes.

So we can edit the code on the host and run it in the container without re building.

Once we get a bunch of diagnostics publishing to spearMCT, it would be nice to save a few premade configurations here or in that repo.

I think this is because we need to get the right gazebo plugins installed in the docker image.

It was probably inconsistent, but I think camera_depth should have been what I went with.

Webcam 1 is calibrated right now, but webcam 2 and the ZED camera are not. This issue is particularly important for the ZED camera, since its point cloud quality is horrible right now, so hopefully calibration will fix that.

The window exits/crashes as soon as any of the knobs or sliders are clicked

We would like to have more scenarios to run the autonomy simulator in.

We want both a wider variety of gazebo worlds (with different terrain) and obstacle/goal placements.

This package might be a good place to start:
http://wiki.ros.org/hector_gazebo_worlds

This is probably either an error with transforms or just with r p y angles in the urdf. The camera feed appears to be oriented correctly in rviz however, rtabmap produces a map which looks like it's on its side.

Some ROS packages (e.g. the turtlebot packages) organize their launch files by putting files included by top-level launch files into package/launch/includes/<something>.launch.xml. We should consider doing this, or something similar. Therefore:

• non-top-level launch files no longer show up in roslaunch tab completion (since they are named .launch.xml)
• the hierarchy of included launch files is clearer

We can interface with the rover hardware through the rover controller (which is implemented debatably correctly).

Diff drive controller isn't working correctly yet though. The problem - I believe - stems from the importing of URDF.

When you run the diffdrive.launch file from spear_simulator it works, while running an equivalent launch file in spear_rover does not. They pull from the same URDF file. I think the big issue is that it's trying to connect to/load controllers that don't exist, and it just kind of panics or something.

The likely solution is to modify the rover URDF file so it matches with the CASE_hardware_interface, or to modify the CASE_hardware_interface to fit with the URDF, or a bit of both until we have a "proper" description and controller.

Some are using CamelCase, some are using under_scores.

This is fine, but CamelCase is reserved for stuff that directly interfaces with CAN, and under_scores are for everything else. Things are kind of mixed atm.

This node should take a parameter which is the name of the service to call to reset odometry (this is different on the zed camera vs. the simulator).

The node should detect when visual odometry has been lost for over a certain period of time (ideally set through another param) and call the reset service. Once, odometry is reset, it should set the pose to the last pose before odometry was reset.

This allows us to use visual odometry for absolute position in the ekf while still being able to recover from visual odometry becoming lost.

The ZED camera uses different topics, nodes, etc. from the simulation camera so I need to make sure they have the same interface as what works in simulation right now. This includes rgbd-sync, namespace/topics, etc. Also maybe look at gazebo plugin settings (e.g. fov).

Should explain difference between rosdeps and regular apt deps

This is causing the build to fail

We currently have no imposed style guide for xml. Since all of our launch files and .urdf models are in xml, we should have a consistent style.

We need to:

1. Pick a commonly-used style guide for xml (preferably with 2 space indentation since this is what we are mostly using currently)
2. Integrate xml linting in the travis build so that the build fails when there are style violations.

Also, remove launch files which are no longer needed.

This is required to build

Currently there is a React app which does this using the Google Maps Javascript API, but this is separate from rviz.

Also, could possibly add height information.

Once we have images streaming to the rover, or as part of that, we need to do some long-distance testing to make sure our approach works.

the docker build is currently failing but the travis script passes anyways.

Right now several models (e.g. the grey wall model) are not part of the docker image. Rather, gazebo downloads them on the fly from its model database (this repo, I believe) and saves them to ~/.gazebo/models. This happens the first time the model is needed in a docker container. This means

• We need internet access to use the simulator in a newly-created container.
• Anything that uses the simulator will start up much slower in a newly-created container (it takes a minute or so on my laptop) and will freeze gazebo.

To fix this, we could download the models we need (or just the entire model database) and put them in ~/.gazebo/models. This could be done in unpack.sh or possibly within one of the dockerfiles.

We should move all the build and runtime dependencies into one script. Currently, the dockerfile only has build time dependencies.

The move_base node is complaining that it's not receiving one of the point clouds that rtabmap should be publishing.

move_base is producing warnings like this:

The /planner_cloud observation buffer has not been updated for 192.68 seconds, and it should be updated every 2.00 seconds.

There is a remap in nav.launch:

    <remap from="/planner_cloud" to="/rtabmap/cloud_obstacles"/>

This remap means that move_base is actually subscribed to a topic called rtabmap/cloud_obstacles.

I did rostopic echo /rtabmap/cloud_obstacles and it looks like this topic is being published but it appears to not be published frequently.

I'm not sure if this is an error with the way launch files and topics are set up or this is a matter of rtabmap not producing the cloud_obstacles map fast enough.

We need a node on the rover (or at the station, or both) which publishes diagnostics to the diagnostics GUI (for example, looking at CAN node status or network connectivity). There's already a diagnostics.py in spear_rover, so you could build off of that.

Add more specifics here once we do some brainstorming.

We will need to figure out which of our ROS packages require each package.

A potential concern with the solution in simulation is that it uses the IMU as its absolute orientation reference. Need to test this in the real world.

We would like to have some sort of GUI to monitor diagnostics such as:

• Battery charge
• CAN node statuses
• Localization status (i.e. if it's lost)
• Various networking parameters (ping time, dropped packets, etc.)

We'll probably think of more things to monitor later so it'd be a good idea to create this GUI in such a way that it's easy to add modules.