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

Check if constants should be replaced by user-configurable parameters #35

Open
rokusottervanger opened this issue Feb 15, 2022 · 4 comments

Comments

@rokusottervanger
Copy link
Contributor

In a few places, there's magic numbers in the code. We may want to get rid of those. Some examples:

#define RADIUS_EPS 0.001 // Smallest relevant radius [m]
#define VELOCITY_EPS 1e-3 // Neglegible velocity
#define LONG_DURATION 31556926 // A year (ros::Duration cannot be inf)

#define MAP_PARALLEL_THRESH 0.2
constexpr double DT_MAX=1.5;

// Upper and lower saturation limits
double upper_limit_ = 100.0;
double lower_limit_ = -100.0;
double ang_upper_limit_ = 100.0;
double ang_lower_limit_ = -100.0;
// Anti-windup term. Limits the absolute value of the integral term.
double windup_limit_ = 1000.0;

@Timple
Copy link
Member

Timple commented Feb 16, 2022

#define RADIUS_EPS 0.001 // Smallest relevant radius [m]
#define VELOCITY_EPS 1e-3 // Neglegible velocity

These are meant for numerical comparisons. Like in c++ you cannot compare floats directly. But good practice is not to use EPS itself but choose a domain-specific smallest number. So I think these can stay without being parameterised.

#define LONG_DURATION 31556926 // A year (ros::Duration cannot be inf)

This is a workaround for INF missing in the message. For Robot domain I think we're good here.

I agree that all others can be parameterised.


Is it worth doing though? Without someone actually asking for this, it just makes the package more complex.

@lewie-donckers
Copy link
Contributor

Just to be 100% sure we're talking about the same thing:

A magic value is an unnamed literal value which is directly used in the code. The examples you listed above are constants and that's fine. Maybe they can be replaced with variables, removed or given more descriptive names but they are not magic values.

Not a magic value:

double upper_limit_ = 100.0; 

Magic value:

      if (abs(new_nominal_x_vel) < 0.01)

@rokusottervanger
Copy link
Contributor Author

I stand corrected. Nonetheless, at least some of these values should be made configurable for the user. Do you have a suggestion for an alternative issue title?

@lewie-donckers
Copy link
Contributor

I stand corrected. Nonetheless, at least some of these values should be made configurable for the user. Do you have a suggestion for an alternative issue title?

"Replace constants with user configurable settings" of
"Check if constants should be replaced with user configurable settings"?

@rokusottervanger rokusottervanger changed the title Get rid of magic numbers Check if constants should be replaced by user-configurable parameters Feb 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants