cc @chatrasen @satyeshmundra

Any robot deals with points and other data types on multiple coordinate frames and we regularly need to transform these points from one to the other. But the transformations between these frames keep changing with time! And different modules have the information needed to tranform between some two frames.

Remembering which module handles which frames and having to write the rotation and translation matrices for all the intermediate frames is a tedious task.

We need to have as few frames as possible and also few modules that handle the transform between them. Therefore we need to list down all the frames needed/present and decide which transform is handle by which module.

We will be using the tf package.

There will be a file (something like yaml file) where all the dimensions, parameters, etc. of the bot like, length, breadth, wheel to wheel length, wheel radius, etc. will be mentioned. This will enable us to write the programs that can be supported on many vehicles and bots only by changing a single file. This file will be loaded by any program that wants to know any physical dimension of the bot/vehicle.

MRPT already uses a config file to do this. Read more about it at mrpt::utils::CConfigFile.

minimal

Lane detection and grass removal are logically separate and lane detection need not know about how grass removal is done. Hence, there should be a separate abstract class for data pre-processing, from which grass removal will inherit.

expected behavior : Target curvature, target velocity and integral part of both the PIDs should become zero.

current implementation: button press for making the part zero is only check in manual mode.

Hint: Update variable names and check commonly on both the conditions.

@manujagrawal Push the changes that were done on your machine.

All the sensors will be publishing their status, like for example if they are alive, suspended, being read from, etc. for the fault tolerance system to judge if all the sensors are functioning properly. This will save us a lot of time while testing.

@thesidjway @shubh-agrawal The controls README mentions how to do what but nowhere it mentions why something is being done. Why have you added XBee for example. Why Arduino Due? etc. in every paragraph of the readme. Just one line additions to explain what is being done would help a lot to the ones who are reading it.

@abinashmeher999

The error in the above image was obtained when we did 'rostopic echo /move_base_simple/goal'.
Also, in this case i had set all the frequencies (update as well as publish) in the config files to 0.5 Hz.

We have very poor documentation of our code and that too everything is within the code. So, exploring the codebase is tough.

We need to begin documenting any further code written and generate the documentation page from that. We will be using doxygen style documentation inside the source, generate html pages from it using doxygen and host it on gh-pages.

The task is to

• Write the config file for doxygen
• Properly host it on gh-pages

This is a fairly easy task.

The bottom left panel is for node to change perception result from bot_frame to odom frame
it keeps saying that argument target_frame does not exist
the function lookuptransform could not be found in the code.
We only changed /odom in the code to /odometry/filtered as we were using the latter topic

@abinashmeher999
@shivamvats

cc @krishna95

cc @hargup @abinashmeher999 @kumarkrishna @krishna95

ToDo

• Choose a testing strategy
• Write a debug mode for the code with nice stacktraces
• Choose a testing framework

I believe this will make controlling the bot a lot more easier and fun.

Take this as a general guideline for what should be the controls.

minimal-branch

Localisation is of a robot=> It should be in the Robot folder
Mapping is of the environment=> It should be in the Environment folder
@todivasudha

Even when i removed the gitignore, I am not able to see the file in my git status
@abinashmeher999

Currently all the required ROS packages are kept in our code.

@kaustubhhiware @aranyadan Please add a README.md for this

cc @prabhat1081

The task is to standardise the path segment that will be given by the planner to the controller to realise. The controller will be a separate module that will take the path segment as the input and make sure the bot stays on and follows along the path segment. The controller is a different module to be able to facilitate different controllers possible for different kind of drives. So, by changing the controller only the same path segment can be realised on a different drive.

The basic task of the controller will be to take the path segment and give such velocities to all the wheels so that the bot follows the path segment.