gtagency / buzzmobile Goto Github PK

Add __init__.py to buzzmobile/buzzmobile/ and elswhere if necessary, setup from buzzmobile import _______ throughout the project.

The chain makes clicking noises occasionally as driving straight and clicks very quickly when turning sharply. It doesn't really sound right.

The chessboard has to have it's size in the final image defined by the pixels_per_m param and by the real world size of the chessboard (which can be a param too).

Additionally, the projector node has to use the image_height and image_width rosparams.

Blocked by #7 to have final key location instructions.

Also add instructions for static maps api key (needed for route_mapper node).

Create tensorflow models for road detection

Following some discussion in #61, it might be better if we factored out parts of the travis ci build script into a install.sh, so that

git clone
./install.sh

would install system dependencies, run setup.py, install rosdeps, etc. and allow deployment to be done the same way across all systems.

Currently, in buzzmobile/sense/gps we have bearing.py, interpolate.py, gps_mapper.py and maps.py which should be moved to buzzmobile/process/gps_mapper.

blocked by route mapper not yet existing

Document how to start up ROS, turn on and enable the car, and get it to drive.

Currently, we have no horn. But with the assumption that we will get one (this is pending discussion):

Shouldn't car_interface also process CarPose for handling turning horn on and off? Why do we need a separate node and separate message simply to say "horn is on/off", when the CarPose will already encode this information? (and if it doesn't currently encode it, it should shouldn't it?)

The Arduino should know if the car is e-Stopped. Right now something is disconnected. Debug in conjunction with RJ if necessary.

http://wiki.ros.org/unittest

These will automatically be run by travis ci at every push.

And remove install instructions from readme

buzzmobile/mission_control/route_mapper.py -> buzzmobile/route_mapper/route_mapper.py

@coletaylor788 I want your opinion on this:
buzzmobile/sense/controller.py -> buzzmobile/plan/controller.py (or process/)
Mainly because controller outputs a CarPose, so it does the planning

Having a map of nodes and messages would be useful for future reference.

If you run image_const gps_model, a lidar bag, lidar_to_frame, frame_merger, steering, some of get Killed because they go OOM sometimes. We need to investigate why.

Add google maps key and keep it private so other people don't use it.

Also it currently exists in the git history, so we may want to go ahead and expunge it from history as well.

Should be similar to instructions for gps node

Also add as dep in package.xml

AUTO/MANUAL

Such as two of the image_const nodes (we only need one, and it should arguably live in tools).
Or even the lane_detector, which we are scraping for the future road_detector node aka agencynet

if(digitalRead(estop_pin) == HIGH) is never evaluating to true, even when the estops are disabled. Since this never evaluates to true, the car never moves. Commenting this if statement allows the car to run but it was likely important and should be fixed. Here is the comment from the code:

/* Only run the controllers if the motors are enabled.

• This prevents the controllers ramping up while the
• vehicle is estopped, creating a dangerous situation.
  */

steering.py should not be using a rosparam breaking_distance, it should calculate a breaking distance based on the current speed and other features of, say, the motor.

This will probably be something to figure out when we have a real-world odometry interface. See #41

Takes polyline and saves it, outputs a gps frame at every NavFix received

See for yourself by playing the following bag from the Agency drive:
stationary-one-moving-one-static-pedestrian.bag

This includes...

• measuring wheel_base
• re-measuring wheel_circumference (the rosparam we have was taken from buzzmobile-old)
• re-measuring max_steering_angle
• considering changes to the way we compute travel_distance

About the last point, right now, travel_distance is a value that is a "good enough" approximation of the distance travelled per tick. In buzzmobile-old, this was computed by the odometry interface, which assumed that the car was moving at a constant speed, and published:

distance_travelled = (ticks_elapsed_since_last_keep_alive * wheel_circumference) / ticks_per_revolution

We don't have odometry interface anymore, and we don't need it, because we're not simulating the car in the world model to make decisions about what to do when in a future state. So, to us, travel_distance can be an approximation because all it does it codify the granularity of the tentacle points. But I wanted to make sure this was mentioned somewhere ack'd

https://github.com/gtagency/buzzmobile/pull/32/files#diff-803bc1ddda718a341d80de27f0125f74R14

Explaining what goes in the folder, and node-specific explanations, instructions and caveats

sense/inputer/repl.py -> sense/inputer/inputer.py
lidar_node should be lidar_to_frame

It disconnected again today, and I'm worried I might not be connecting it properly, so I'd like to get someone else fix it.

if two tentacles have the same score, the one with the smallest angle wrt to the current heading (0 rad for now, odometry heading in the future) should be picked.

Get a controller, PS4, PS3, etc. working with the ROS Node over bluetooth.

Code should work, has not been tested yet

Should take map_querier's polyline and the current NavFix and output a route_map image gotten from google maps' static api (example code in buzzmobile/tools/mapper/mapper.py)

Also note: only query every 8 secs, and every time new polyline is published, so we dont run into our daily limit

Following discussion in #33, we need some way to get real world motion to help with planning.

:(

@joshuamorton @dacohen please chime in