uf-mil / mil Goto Github PK

The Network box is in a non-functional state. When plugged into SubjuGator, there is a yellow status LED on the ethernet connection, but no green LED indicating network connection. Also, the netbox needs to be documented so in the future if it needs to be fixed / replaced, we have a reference.

In VRX, using vrxviz you can see points for objects move in the global frame (ENU) when NaviGator moves.

This is likely an issue with transforms, as everything seems okay when viewing things from the perspective of the lidar

UGRENT. Blocks working mapping in VRX

Currently the documentation home page just contains a table of contents. More friendly information should be provided here

Write a rostest, that will open up the SubjuGator simulator and execute some discrete moves ala submove f 5 submove yr 30deg, and verify (programmatically) that the Sub gets there.

This run should be added to a catkin project within the repo, so it is run by CI.

Put the test into sub8_missions

ROS interfaces
/odom -> position + orientation

/move_to/goal -> New move goal (position + orientation)

Be sure to use the rostest library

Stretch goal:

• Random goals

Add scripts to make it easy to run multiple instances of the development container WITH x11 forwarding and networking to allow multiple developers to use Zobelisk/Shuttle to run simulations simultaneously while networking to their local development machine

Given the resources needed to run sim, this is fairly low priority. This should be combined with systems to reserve time on Zobelisk/Shuttle (see previous slack message in #software).

Install the GPU Drivers on shuttle

Important changes made to SubjuGator at RoboSub 2019 were not pull requested or merged, and therefore were not included when SubjuGator was merged into the monorepo.

After reviewing the changes and cleaning them up for readability, merge these changes into the monorepo (git should handle this smoothly as the files were moved from the repo)

Task 6 perception to scan the LED sequence pattern

For Dr. Crane / showing at meetings

run stationkeeping and wayfinding missions in various scenerios and report the scores

How to setup system, submit pull request, etc

LQRRT was a great experimental work and served us well, but we need something that is better documented and performs better. Another design priority is making is small, e.g. it doesn't need to do anything more than provide trajectories. Use ROS design patterns to separate concerns.

Add an extremely valuable integration test which will spawn the NaviGator simulation (VRX) and command a move through the mission system, ensuring that the mission completes and the odometry now reports the desired pose.

edit the yaml files under navigator_gazebo/simulation/urdf/navigator_vrx/ to actually reflect thrusters and sensors on navigator

Code says
[WARN] [1570660183.915060, 123.181000]: Failed to resolved robot.server: [Errno -2] Name or service not
known
please make stop

Get a bunch of cropped sample images of the various VRX objects (mostly different colored totems and sphereical buoys). Run with a bunch of different vrx worlds to get different lighting / fog conditions

Currently will crash

could be controls, or state estimation related

Confirm that the Sub8 simulation can run on 18.04. There may be small changes that need to be made (changed API, gazebo deprecation, new dependencies needed in install script, etc). Make these changes and add a docs page re how to run the sub8 sim

As expected, the current repo cannot build as the merged repositories (mil_common, NaviGator, SubjuGator) were previously built on 16.04/kinetic, while the new build process is 18.04/melodic. The changes needed are likely trivial.

TODO: better description

See VRX rules re the docking task. We need a computer vision node to detect the color and shape of the elements on the dock. Given the ideal conditions of VRX, I feel confident this could be solved in a reliable way using traditional computer vision (OpenCV, edge detection, HSV color thresholding, contour and polygon approximations).

We have some existing solutions for the real-life instance of this challenge (several in navigator_vision, including one using a ML model. These may be useful references, but the simulator will require at least different tuning or perhaps a simpler approach altogether.

Currently our aliases don't work

Solve the Traverse Navigation Channel mission in VRX (see task description pinned to slack).

Will likely use the work in #29 to get totem color, but this issue is more for the mission code

On slower machines, when running the sub in gazebo, odometer gives the wrong position (transform from map) even when the simulation is paused.

It can be seen by running the simulation with gui:=true and then running the subviz.

Many last minute hacks were done to PCODAR for VRX, look at the recent diffs and make sure we didn't mess it up too bad

Like we used to have w/ Jenkins

expand navigator_launch vrx.launch to actually use navigator_vrx.urdf

Things to research:

• ROS image transport and cv_bridge (to get an image through ROS)
• Extracting a ROI from an image (this ROI will be given to you)
• Analysis the histogram of an image (potentially using HSV) to see the significant colors (filter out the ocean, etc)
• Classify on color using simple thresholding or (more reliably) a Bayesian classifier

ci-build containers is always built off the mil base container that existed when the buildkite client was started, instead of rebuilding the base container. This should be solved using args

TODO: confirm we want to continue to support the use of pointgrey cameras.

Currently the docker containers do not have the option for importing the closed source flycapture libraries used by mil_common/drivers/pointgrey_camera_driver . This used to be done on host systems by the scripts in https://github.com/uf-mil/installer . A similar system should be implemented such that the user is prompted by the build docker images script for the password.

Please comment if this description is unclear or you differing/better implementation ideas.

Got to pcodar, grep for footprint, find the TODO

Currently builds are failing because the source directory is mounted as root into the CI container

The utility scripts for building / running docker containers currently require root, but they should really allow either root or a user in the docker group.

VRX gives us an IMU and GPS on ros topics. Use a kalman filter, such as the robot_localization to output a unified POSE (position + orientation)

Mainly, move old bag files (before 2018) into offline storage to make room on the file server.

After the monorepo merge, navigator_gazebo will no longer build (related to trivial gazebo api changes from 7 to 9).

Additionally, changes to VRX (which we store as a submodule) has had significant changes which will we need to update to (xacro files, launch files, etc).

Success criteria: Able to build all targets in navigator_gazebo and run the simulator from the development docker container.

Given a region of interest to look for the dock symbol / color, determine which symbol / color is in the frame

currently the dev container does not have permissions if the user running the dev container does not have user id 1000.

MRAC controller currently has hard coded values for WAMV mass/inertia and gains. These should be read from the urdf / passed by a launch file respectively. Also MRAC has a thrust mapper that is no used. It should be deprecated.

• Allow C3 to produce trajectories which turn before moving towards goal, which would be helpful if a robot is faster in the forward direction (sub8 after modifications)
• Generate spiral / circle trajectories
• Have carrot always respect dynamic constraints given current odom. Currently, the trajectory is published the same regardless of if it was followed. I think the controller will be more stable if the carrot waits until the odom reaches the current pose/twist before incrementing

May be due to running on system with AMD gpu