auv-iitk / varun-software Goto Github PK

make remote control show bot current position, what task is running, which topics are being published to.

launch files represents the mode in which we will run code. Ideally we should not need to run nodes ourself. Right now we have 2 set of launch files. One for launching everything with gazebo and one with hardware_layer. But now we have a third case where we would need to run some specific nodes for callibration of pid (on gazebo and on hardware) so I propose we write a new set of launch files which would start hardware layer and gazebo with topic remapping. meaning that the topics from sensors will be renames to topics we use to tell motion nodes what is the current position. Like /varun/sensors/pressure_sensor/depth should be remapped to /zDistance during callibration so that upward node pid can be callibrated using pressure sensor data. similarly for /varun/sensors/imu/yaw should be mapped to /yaw. So we can have launch file in motion_commons which launches motion_nodes.launch along with rqt_reconfig and launches one of hardware_nodes_pid.launch or debug_nodes_pid.launch. Where xyz_pid.launch are the respective launch files with topic remapping.

add udev rules specific to hardware products so that we can access them on a fixed tty. like imu could be accessed at /dev/navstik. Also add it to setup script so it is added in all systems. Remove hardcoded path to hardware like imu code currently has a PATH file which has the path to imu which needs to be removed. .

@siddsax to control IP nodes from task handlers, we directly use system(rosrun ...). But we want to run all the nodes (all ip nodes and task handlers) in parallel so we need to add a switch that will turn on and off the ip nodes. It has already been done in task buoy. The server publishes on a topic (boolean data type) which is subscribed by the ip node that changes a global boolean variable which is checked in a if condition in the main while loop. If that boolean is then only the whole processing of images starts. So you need to add similar check in all the other IP nodes including line detection and line following node.

Although I think it will be a part of the existing arudino code. You just need to make the arduino publish that data to a topic like sensor/data/pressure_sensor

Executable name (declared in Cmake), CPP file name and node name should be same. And it should be governed by CPP file name. For consistency.

Don't use #define for declaring constants. Use const. Read http://stackoverflow.com/questions/4103086/defining-constants-in-c

The code of nodes should not have string constants in them. For example if I change the name of forwardServer from "forward" to something else then everything will stop working. Better would be to give these strings to node from the launch file so that we can see all such strings in one place. also we can use xmacro ros pkg to simplify our ros launch files.

right now gazebo is publishing only raw data. You need to publish the yaw angle for calibrating turn pid on gazebo

• xu4 install lubuntudesktop
• https://github.com/AUV-IITK/AUVWiki/wiki/Setting-up-xu4-or-nuc
• avahi daemon config to some custom url, Setup vnc, ftp, test gui.

which can log all topics and play them back together so we can analyse what happened when the bot was running.

Write the test nodes for all the motion for calibrating pid, also ensure that the sensors do not publish the data directly to the motion library, the data should go through the test nodes and the task handlers.

Should have an abstract and a detailed explanation for new contributors.
Also explain use with VARUN and in gazebo.

Camera Distortion
Sensor Noise

Declare all string constants on top of file, like node name, topic name should be on the top.

Add gravity in the gazebo for the upward motion before the upward PID calibration.

Add a preprocessing node which takes image from varun/sensors/front_camera/image_raw and varun/sensors/bottom_camera/image_raw and fixes camera distortion and publishes to varun/sensors/front_camera/image topic which can then be used by ip nodes. Since camera distortion is in both hardware and gazebo so this can be a part of hardware layer.

cherrypick relavant commits from prakhar's feat/rqt-plugin branch and fix roslint errors

Setup basic setup for documentation and hosting it.

Calculate angular velocity and acceleration integrate to get positions ,angular orientation,would work for short time only. would help in stabilization. Publish msg using official Imu msg. Publish data to sensor/data/imu

It should be in two levels one should be like an abstract and the other one should have detailed explanation for each function. It will help new members to contribute.

Fix gazebo

• respond to motionlibrary output
• simulate sensors data (imu, pressure sensor, camera)
• write launch files to run bot in gazebo so basically have a choice between starting hardware layer vs gazebo

Explain the algorithm and the how to use it.

Add linear algebra to thruster individual functions in arduino code

language - bash/python
usage - change license info, author, email, website
future - can be released as a command line util, with man page and all

Also add cad model to website so visitors can see model in 3D

Restore older arduino node and have 2 nodes as the new node will be used only for testing remote control. The old node where the choice of which thruster to use will be made by arduino node.

OpenCV change image processing nodes to use image from topic and change hardware_camera to publish images on topic. Topics can be named like
sensor/data/camera_front
sensor/data/camera_bottom

publish roll and pitch just like yaw from hardware_imu
also make sure to do so to the same topic as gazebo

launch file for hardware layer is empty right now it needs to start imu, cameras, arduino node

Motion library nodes should take pid constants from the ros launch file through the parameter server. http://wiki.ros.org/Parameter%20Server http://wiki.ros.org/roslaunch#preview

shift all codes to openCV3

In all motions, bot performs an unexpected yaw motion. To prevent this, add goal in the task handlers with infinite loop time that will ensure the yaw angle to be fixed.

All image processing nodes should have a dynamic reconfigure button. on pressing it. image processing node calibrate its constants depending on the image from camera. Basically we tell the code that yes there is a specific arrangement in front of it. Now it needs to fix its constants such that it get starts getting positive results for that data.

Code health is not full. fix missing this listed at https://github.com/AUV-IITK/AUVWiki/wiki/Developers-Guide

Language - bash/python
Usage - Recursively find all package.xml files and set input as version number IF version number is higher than input then roll back changes and give error.

Right now our bot stops the thrusters on detecting the line but goes on drifting due to inertia and the line following node just take the angle and align it to the angle of the line. By this our bot gets displaced and it aligns with the line but the center is not at the line. @siddsax you need to fix this problem. What we can do is first align the bot to the line and then move the bot sway until the line center and the bot center coincides. The direction of sway can be obtained by the position and the angle of the detected line.

Write different sets of launch files with ros params for both robots so no need to run multiple terminals for running bot And nodes should read parameters from there.

Edit current taskhanders for only one motion at a time, rest all will run for stabilization.

Curently we are only using <velocity_decay> to simulate frictional forces. For buoyancy the weight has been set to zero. This has to be changed. Changes:

• Set realistic weight and inertias
• Use Hydrodynamics plugin for bouyancy.
• Use Aerodynamics plugin for lift and drag.