Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changing all ROS_RATE occurences to ROSParam #99

Open
wants to merge 6 commits into
base: indigo-devel
Choose a base branch
from

Conversation

pranaypratyush
Copy link

No description provided.

@prudhvid
Copy link
Contributor

Great work! @pranaypratyush changing params over so many files is really appreciable 👍
cc @kalyan-kumar @ghostwriternr

@pranaypratyush
Copy link
Author

@icyflame umm. ok but changing all those files again would take some time.
@prudhvid thanks.

@icyflame
Copy link
Member

@pranaypratyush Use git rebase -i. Find a tutorial online, or get help from @kalyan-kumar. You will be able to change only the commit messages, and leave everything else untouched.

BTW, Good work 👍

@icyflame
Copy link
Member

@pranaypratyush TODO:

  1. We are not using Scripts/launch/*.launch files, only the Scripts/launch/simulator/*.launch and Scripts/launch/vehicle/*.launch. So, revoke your changes to those files. They are there for legacy reasons only, and may be removed with a commit down the line as well. (cc @nevinvalsaraj )
  2. Change the handling of the case when the rosparam is not defined. Instead of setting a default rate, throw a RuntimeError and exit out of the node.

@pranaypratyush
Copy link
Author

Shouldn't I use ROS_ERROR instead of RuntimeError ? And ros::shutdown() to shut the node ?

@prudhvid
Copy link
Contributor

Yeah @pranay you should do that
On Jan 12, 2016 6:51 PM, "Pranay Pratyush" [email protected] wrote:

Shouldn't I use ROS_ERROR instead of RuntimeError ? And ros::shutdown()
to shut the node ?


Reply to this email directly or view it on GitHub
#99 (comment).

@icyflame
Copy link
Member

@pranaypratyush @prudhvid ROS_ERROR is for printing, it's one of the log levels (like DEBUG, INFO, etc), not an exception.

In python the exception itself is called RuntimeError, so you should print to ROS_ERROR and then, throw a RuntimeError so that the stackTrace is available to the user.

@pranaypratyush
Copy link
Author

@icyflame What about in c++ ? C++ doesn't show stack traces ( I think ). So do I use RuntimeError there too ?

@icyflame
Copy link
Member

I think there's a mechanism. RuntimeError does not exist in C++ AFAIK. It's called something else. @kalyan-kumar ?

@icyflame
Copy link
Member

btw @pranaypratyush Next time around google before coming here!

@pranaypratyush
Copy link
Author

I actually google before asking here. Why the hell do you think there is so much time gap between the comments ? I found out that 'std::runtime_error is a more specialized class, descending from std::exception, intended to be thrown in case of various runtime errors.' But it won't show the stack trace (obviously). To show the stack trace I would have to do this.
Now the question is do I really need to go through all this ( I mean displaying an error saying 'parameter not present' seems pretty damn sufficient to me ).

@icyflame
Copy link
Member

Um, so apparently, the stack trace can be seen by using gdb. So, you can peace-out on the stack trace, but the exception must be thrown, and the name of the parameter must obviously be a part of the message shown.

@pranaypratyush pranaypratyush force-pushed the ros_param branch 3 times, most recently from 7be450c to 9e824d6 Compare January 13, 2016 13:41
@pranaypratyush
Copy link
Author

@icyflame @prudhvid made some changes take a look at them.

@icyflame icyflame changed the title Fix for #98 Changing all ROS_RATE occurences to ROSParam Jan 13, 2016
- Modified all occurences of ROS_RATE in .cpp files to
  accept a ROSParam double instead of always using
  a default value.
- Fixes auviitkgp#98
- Modified all occurences of ROS_RATE in .py files to
  accept a ROSParam double  instead of always using a
  default value.
- 'yaml' file is yet to be added.
- Fixes auviitkgp#98, only for `.py` files
- Created a new `yaml` file under
 `Scripts/launch/yaml/ros_rate_param.yaml`.
- Modified all `.launch` files to load the `.yaml` file.
- Fixes auviitkgp#98, adds `yaml` file
- Modifies `.py` files to throw `RuntimeError` and show
  stack trace when `/ros_rate` not found.
- Modifies `.cpp` files to throw `runtime_error` when
  `/ros_rate` not found.
- Reverts back legacy `.launch` files to original state.
- Other fixes regarding `ros::NodeHandle`.
- Fixes auviitkgp#98, exception handling and debug commit
@icyflame
Copy link
Member

We are not using Scripts/launch/.launch files, only the Scripts/launch/simulator/.launch and Scripts/launch/vehicle/*.launch. So, revoke your changes to those files. They are there for legacy reasons only, and may be removed with a commit down the line as well. (cc @nevinvalsaraj )

@pranaypratyush

else:
rate = default_rate

try:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

try and except are not at the same indentation level.

@icyflame
Copy link
Member

@pranaypratyush See the above line comments, and fix them. Also, revoke the changes done to legacy / unused files using git checkout indigo-devel <filepath>.

This will make the diff more streamlined.

sys.exit(0)

r = rospy.Rate(temp_rate)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aniket11bh @kshitijgoel007 @VishnuDuttSharma We should change these rates to the global constant right?

@aniket11bh
Copy link
Contributor

No, you should not change these rates. Because It is the frequency at which data is sent by the sensors. If the rate become low then it may cause buffer overflow causing blocking of data.

But, we can change the rate at which sensor data is published by the node. Which is not written separately in our current code.

Also, need to fix the problem of DVL package not getting any data somtimes.

@icyflame
Copy link
Member

@pranaypratyush there you go. Revoke the changes in the sparton, nqDvl packages as well. Use git checkout indigo-devel)

@pranaypratyush
Copy link
Author

So do I edit my last commit or create a new commit ?

@icyflame
Copy link
Member

New commit.

- Also debugs some indentation issues that
  crept in during the last commit.
@icyflame
Copy link
Member

@pranaypratyush Still to revert trax, sparton, nqDvl. Also, run the hooks/formatAll.sh script to make sure your CPP files are indented properly.

@pranaypratyush
Copy link
Author

So I am reverting all changes to all files under sensor_stack. And why is there a branch conflict ? How do I know where it is ?

@icyflame
Copy link
Member

@pranaypratyush Rebase this branch. Since this PR was taking too long, another PR ( #101 ) was merged into the main branch.

That moves all the unused files into obsolete/. So, when you are done with this PR, none of the files in obsolete should be touched.

@pranaypratyush
Copy link
Author

@icyflame Ok so I have reverted all files in sensor_stack to the indigo-devel branch. And merged my indigo-devel branch to current. Everything seems okay now.

@icyflame
Copy link
Member

@pranaypratyush LGTM. We will merge this once we have tested this on the vehicle.

@icyflame
Copy link
Member

@pranaypratyush If you are testing the vehicle, you must test this out. And if it works, then we should immediately merge it. Not having it on master could cause problems later.

@icyflame
Copy link
Member

@pranaypratyush @Nightfury18 This has been tested I think. The diff looks fine to me, and I will merge it by tonight unless one of you can bring up an issue with the PR :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants