uf-mil / mil_common Goto Github PK

Refactors for the passive sonar system. Some of these will be pushed upstream to Sylphase's passive sonar system:

• Move some of the processing from pre-ROS to post-ROS, so more raw data can be collected in bag files
• Fix bugs related to interrupts. Sigint does not correctly terminate the upstream program
• Implement visualizations in more ROS-ified ways (RQT, Image published, etc)
• Make constants configurable, tuneable
• Collect bags with raw data to experiment with improving the system

Call service to reset PCODAR (forget all objects / pointclouds)

As we're going to be using sub8's valve board on NaviGator, this driver should be moved to mil_common.

Additionally, as we will be using multiple of these physical boards, the driver should add support for multiple boards (similar to the sub8 videoray driver).

Move the c++ library in uf_common (now mil_msgs) and any scripts to mil_tools.

I'm working on this.

Please list all files you want migrated from sub8 or navigator to the software-common repo. List the full path of where the file is from, and where it should go in the new repo. If the file is going to be a merge of sub8 and navigator files, say so.

For now we are just worrying about getting the files in the repo. We will go through and refactor later, but feel free to leave notes on what needs to be done.

The Wiki is missing a write up on how to use the passive SONAR. Readme of passive SONAR has legacy command of: "rosrun mil_passive_sonar sonar.launch."

The multilateration in mil_passive_sonar is fairly naive. Explore methods other than least squares or a more guarded version of least squares.

New dependencies have been added in the install script, so the Docker image has to rebuilt to provide accurate build info

Add support for multiple boards in one node of mil_pnuematic_actuators, for NaviGator's plan to have multiple boards for all of its valves

Recommend forking http://wiki.ros.org/libuvc_camera, adding the extension units found at https://github.com/econsysqtcam/qtcam/blob/master/src/see3cam_cu20.cpp

IDEALLY, we contribute most to the ROS community by creating a generic system for interfacing with UVC extension units, not just the ones present in this camera, then PR to the ROS driver.

Metaticket for various improvements to mission gui:

• improve timing of feedback
• sort missions alphabetically
• save/load chained mission config

• Add option to PCODAR to classify objects based on their volume, height, or other simple features
• Ideally, the classification system would be modular (an interface different methods can fufil)

Write tooling/library/messages for nodes detecting objects in the 2D frame of a camera, or 3D poses for systems using PnP / stereo.

This system will be similar to the vision proxies system on NaviGator.

Ideas:

• A single message shared by vision nodes for reporting what was seen, frame, confidence, additional attributes, etc
• A base python "server" class for subscribing to a camera, finding objects, and reporting them via this message
• A python "client" class for missions / visualization tools which connect to vision servers and keeps track of objects / can wait until something is seen. Should provide a TxRos implementation for use with mil_missions
• A gazebo plugin to report ground truth objects seen in camera
• An implementation for the "client" which uses tensorflow

Originally proposed by Tess:

On NaviGator, we have a pretty accurate transform from our GPS/INS to the LIDAR because it is rigidly mounted with simple geometry (the CAD model tells us). However, the camera transforms were measured and likely have significant error. It is mathematically possible to recover the pose of the camera in the LIDAR frame by identifying the same features in a LIDAR pointcloud and an image frame. This would improve our transforms.

SujuGator's network broadcaster is non-project specific and should be in mil_common.

details to come

• If objects are currently within field of view, but have not been seen (new points associated) recently (configurable time), remove the object. This is useful, for example, when a kayak moves by the boat and then leaves.
• If an object is currently seen (in view and new points associated), remove older points associated with that object. This will allow the object to "move" over time if it drifts without "smearing"

Just some reminders for me:

• fails when using device, not file (because checks ping count)
• param min range profile threshold is not used
• DNS doesn't work maybe?

Write a generic interface for thruster mapping in 3D (body wrench to individual thrust efforts). Some ideal features

• Option to parse URDF file to find thrusters (joints identified for a prefix THRUSTER_)
• Inheritance based for other minimization functions (minimize energy, faster processing, etc)
• Function to disable/enable on the fly (when thrusters are broken, etc)

To make the online bagger more useful on test days, it should integrate with the bag command we made in two ways:

1. Online bagger should read the same environment variables the bag utility does to decide which topics to buffer. Perhaps instead of adding all of the bagging topics, it would add all the topics in a certain reserved variable, like bag_online, so the bag utility configuration can specify which to bag ex: bag_online="$bag_frontcam $bag_gnc"
2. Add an option to the online bagger service to dump a list of topics (space separated). This will allow the bag utility to add a new flag for dumping the past n seconds with the specified topics.

Had a weird issue at navigator test day where a task had a dictionary error, and the task server simply responded with aborted and the key as the error, confusing me. It should return a more descriptive error, ideally with a stacktrace

I think it would be more appropriate for the triggering of bag writes from online bagger to be through the ROS action API than the ROS service API.

Why?

• writing large (many gigabyte) bags to disk can take several seconds, which will cause clients (such as alarm callbacks, missions, etc) to freeze for this time
• actions allow a feedback, which will notify the user from the client side which topics are buffered, how many messages, etc instead of having to look through online bagger logs
• actions have built in preempt functionality, so new bag actions can be canceled or superseed current ones
• would make future functionality, like storing new messages even as a bug takes place easier to implement

So you can see a description / usage guide for a task. Either static (written to ROS param) or dynamic (call a service, may change based on status).

Add software into mil_common to interface with the sylphase passive sonar board and perform higher level signal processing to obtain a heading to a ping or position estimation.

Some notes:

• Add message files for Ping, ProcessedPing, and Debug
• Refactor the work in sub8_hydrophones
• Refactor NaviGator work pinger_locator.py and pinger_finder.py
• Refactor #17 (ideal)

• TXROS class for receiving vision object updates
• Node to draw objects onto an image for visualization
• Node to multilaterate objects for 3D pose
• Node to use PnP for 3D pose

We should create a list of things to add / migrate to software-common

Commit a new .mbs and .hex file (with higher version number) to our fork of robot_eq driver, which sets the PWM frequency optimally for pinger

A few things that need to be done post-great integration:

• Merge SONAR OS (Sujugator must be updated to use it too)
• Generic-ify perception/mil_vision/object_classification/lidar_to_image.py (currently uses navigator specific things)
• Remove sub8 dependency from perception/mil_vision/ros_tools/easy_thresh.py (uses sub8_vision_tools.visual_threshold_tools which is not in mil_common)
• Document everything (especially mil_vision_lib), get rid of redundant / repeated code in libraries

All of the common tools should use tf2_ros, not tf.

The mission and perception code should also be migrated to tf2_ros.

@uf-mil/developers any takers?

Play some sample data with known ground truth pinger position, make sure the script finds something within an error tolerance

The occupancy grid produced from known objects seems to be consistently off in position from the lidar points it should be filled from. This is likely an off-by-one error with filling the occupancy grid matrix.

If user Control-C's a runtask command, it should catch this and cancel the task

runtasklocal <task> <arguments> -> start a task server, run task, and close

Spurious (non-existing) objects are added from waves on NaviGator. #129 will help, but try new filtering methods too.

Here are some ideas:

• Use radius fitler instead of statistical outlier. I'm worried that the persistent pointcloud will throw off the standard deviation (identical points drive it way down)
• Add z pass through filter (will be a problem for the smallest buoys)

Missions is a more appropriate name, more consistent with previous MIL work. This change will reduce confusion.

We had to temporarily disable building a couple programs in mil_vision in #95 because of a change in some OpenCV data type. There is probably an equivalent. So uncomment the lines commented in this PR, see what the build errors are, and fix it.

As discussed in the last two meetings, we are developing a branch of LabelMe to label logged data with object polygons for testing and training. We discussed producing bag files from these labels, containing images and the labeling data. We also discussed having a python class which will play these special bags and, provided with a verification predicate, assess the efficacy of a vision algorithm. I will be PRing the message files we agreed for storing this data.

@tessbianchi can you write the tooling needed to produce these bag files from the labeling data? Note: the bag should contain all the images of the original bag, not just the labeled images.

There's a really nice python tool called easy_thresh we ported from Subjugator. It seems to be broken on ros kinetic / 16.04. It still runs fine on my 14.04/Indigo system. After selecting a region to threshold, the 3D plot of the colors in this region opens briefly, then crashes, with a segmentation fault being reported in the terminal that opened it and no other errors. I tried my hand at fixing it, but it uses several libraries I have no experience with. Does anyone know who originally wrote this?

Add a node to replace the "fake objects" from navigator_lidar_oa. This node will allow humans/programs to place named markers in the global frame marking points of interest. This allows us to program in "priors" on where various challenges are, so the autonomy can explore these regions.

Some features to include:

• Service to spawn POI and set its position
• Service/Topic to get POI
• Rviz interactive markers for moving POI
• Save POIs to a file and load them back at a future time