auv-iitk / anahita Goto Github PK

In the packages like task_handler_layer & vision_tasks, there are a bunch of classes designed to do specific tasks, but the design of every class is more or less like others. So, more often than not we just copy paste code when creating a new class which feels stupid sometimes as to why bothering to write so much code for a class which is very little different from other. I propose to create a single base class which has the basic requirements needed by all the other tasks and the specific tasks are derived from it. This way will give the code base better structure and scalability.

Please not that the repository organization is as follows:

stack_name
|----- package_name
        |---- src
        |---- ....

control_layer has been defined as a package when it is supposed to be a stack. Please give it a proper name. Also a README file HAS to be there. Please fix it ASAP.

This refers to the project mentioned in #8.

I have been using catkin tools for a while now and I think it it is way better than the catkin_make that we use. Thus, I think it is better if we check that all current packages can be built using catkin build and use catkin tools in future. There might be a few build issues that would need to be resolved but they can be fixed in the CMakeLists of those packages.

Overview: https://catkin-tools.readthedocs.io/en/latest/
Step-by-Step Instructions: http://catkin-tools.readthedocs.io/en/latest/migration.html#step-by-step-migration

Also, the Travis configuration and README have to be changed accordingly.

Since we now have an underwater light also, so we need to include its code also in our present arduino code to run it.

PR #21 fails Travis CI check and yet is merged which destroys the purpose of using CI in the first place. We need to either fix the code or fix the CI (if that's the issue) but in the end we need to have that green tick so that future PRs aren't incorrectly judged.

The level_mode_controller uses a Thruster::mode(1) function whose return values are used in Thruster::calibartion(2) only. Since the return values of mode(1) are used nowhere else, we can remove it completely if it won't be used in the future. The attached diff file shows the suggested changes for cleaner code.
codecleanup.txt

I was thinking of implementing a push-button setup on the side of the hull, to take an interrupt through the Arduino and start a bash script. (Fed up of waiting 2 mins and wasting time).
We will need to think of how much would have to be running already, and what the script would do.

We have changed to a single message for Thrusters, but we have not tested it yet. We need to find a way to launch the node again if it loses sync.
Currently, we manually launch the code again when it fails, and the thrusters lose on control till then.

I was thinking of implementing something like a Bash script which is capable of this because even if we find something that lowers this occurrence, I dont want to risk it.

While trying to threshold the images during testing, it takes a lot of time, depending on the LAN connection and lighting conditions.
I want to create a GUI module which shows multiple images in the same frame, such as rqt_image_view, but we'll have to implement the entire UI ourselves, as given here.

Since we are going to develop a separate vision_layer , which was before incorporated in the task_handler_layer, so we need to decide its organisation. For now, I have made a basic layout of the layer which can be used as a starting point to work on.

vision_layer/
├── calibration
├── cfg
├── CMakeLists.txt
├── color_processing
├── feature_detectors
├── filters
├── launch
├── package.xml
└── src

Currently error logging in the code is very poor and it becomes tremendously difficult to find a bug in logic of the code. So, we need to improve it so that we can figure out quickly where the fault is.

Currently image_transport publishes several versions of the image such as compressedDepth, theora. After spending a few hours trying to optimise the vision code, I think we can reduce the CPU usage if we turn off these plugins, since a major part of the load is handling the transport of these images.
This link contains what I intended to do, but there is currently nothing such as a disablePlugin feature in my PC.

I tried to build the repo using the instructions in the readme file, but the build is failing with the following error:

In file included from /home/rithvikp/catkin_ws/src/Anahita/motion_layer/src/sideward_PID_server.cpp:1:0:
/home/rithvikp/catkin_ws/src/Anahita/motion_layer/include/sideward_PID_server.h:6:44: fatal error: motion_layer/sidewardPIDAction.h: No such file or directory
compilation terminated.
Anahita/motion_layer/CMakeFiles/sidewardPIDServer.dir/build.make:62: recipe for target 'Anahita/motion_layer/CMakeFiles/sidewardPIDServer.dir/src/sideward_PID_server.cpp.o' failed
make[2]: *** [Anahita/motion_layer/CMakeFiles/sidewardPIDServer.dir/src/sideward_PID_server.cpp.o] Error 1
CMakeFiles/Makefile2:3713: recipe for target 'Anahita/motion_layer/CMakeFiles/sidewardPIDServer.dir/all' failed
make[1]: *** [Anahita/motion_layer/CMakeFiles/sidewardPIDServer.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2
Invoking "make -j1 -l1" failed

I think the bug is reproducible in which case we should fix it so that the newcomers don't get stuck.

@ksakash can you please fix these two services? You just need to make a new branch, and figure out a way how to do this. I am trying to solve this, but it's going wrong each time.

It is very annoying to do thruster testing by writing each and every command on the terminal to test it. We can do it easily by dynamic reconfiguration.

Try and implement a linter to this main repository, Anahita.
An example is from ETH Zurich's implementation: linter.
You may try other packages if you like. Try and make minimal changes to the current codebase.

The arduino_node.cpp uses two custom-made messages included from the package hyperion_msgs. There are problems including the header files generated due to Depth.msg & Pressure.msg. @Mayankm96 can you look into this, as I don't have much experience with Arduino CMake