problem setting lower and upper bounds on unused parameter

[Rémi Cura]

Hello everybody.

First I have to say I use ceres to solve a registration problem, and it works very well and fast.

I was trying to further improve it by setting bounds.
I have two kind of parameters block:
double position[3] (X,Y,Z) , and a parameter block with only one parameter : double width[1].
I successfully setted the bounds for X,Y,Z parameters, it works.

Now when I try to set upper or lower bound of width , it crashes after having set some values.
After some analysis, it appears this parameter is not used in any constraint.

Is it a known limitation of bounds?
 (making it crashes when a bounded parameter is not used in any constaints, whereas it optimises fine without constraint (parameter is not modified, which is the correct answer)?)

Cheers,
Rémi-C

[Sameer Agarwal]

Can you please share the crash log with us?

--
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/0c8210f3-6dd0-4458-a56c-e244792b5c65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rémi Cura]

Of course,
I get :
"
F0115 17:06:12.071280  7968 problem_impl.cc:65] Check failed: it != parameter_map.end() Parameter block not found: 0x8b7a2dc
*** Check failure stack trace: ***
"
it is in the FindParameterBlockOrDie function

I confirmed the problem by creating a constraint affecting all "width" parameters.
It works then.

Cheers,
Rémi-C

[Sameer Agarwal]

a full stack trace please, so that I can see what the calling function is.
Sameer

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/378d094a-3539-4b93-b2ac-aa9b345f254c%40googlegroups.com.

[Sameer Agarwal]

Remi,

Are you calling SetParameterLowerBound on a parameterblock that has not been added to the problem?

You can only call SetParameterLowerBound and SetParameterUpperBound on parameter blocks that are already present in the problem. This happens when a parameter block is used as part of a AddResidualBlock call, or is explicitly added to the problem via AddParameterBlock.

For example if you try doing this

double x = 1;

ceres::Problem problem;

problem.SetParameterLowerBound(&x, 0, 0.0);

this will cause a crash and that is what is going on in your code. When width is being used by the residual block, it gets added to the problem via the AddResidualBlock call and you do not have to worry about it.

There are two things you can do here

1. Check if the parameterblock is present before calling SetParameterUpperBound on it. You can do this via Problem::HasParameterBlock

2. Explicitly add the parameterblock to the problem before calling SetParameterUpperBound. Adding extra parameters to the problem is not a problem for ceres, it will automatically get rid of them internally if they are not used by any residual block.

Sameer

[Rémi Cura]

Thanks for the help Sameer.

For the full stack I can't obtain it. I use QTCreator and cmake, I have a "SET(DCMAKE_BUILD_TYPE "Debug")" in the cmakelist, 
yet I don't have any  other info when crashing (saying somehting about this not being a debug build??).

I'm certain it happens when calling the setbound function.

I think you nailed it :
I exclusively use AddResidualBlock (I don't explicitely use AddParameterBlock).
So if a "width" parameter is used by no constraints, it doesn"t get added.

Following your suggestion, I will use AddparameterBlock on all my parameters before doing anything.
It solves the problem and protect me for potential similar case !

Many thanks,

Rémi-C

[Keir Mierle]

We could probably make the error message more informative in this case. Thanks for reporting!

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/f1b9ffe0-5909-4f80-b6e9-3bcbd3a08b50%40googlegroups.com.

[Alex Stewart]

Remi,

I have a "SET(DCMAKE_BUILD_TYPE "Debug")" in the cmakelist,  

Should be SET(CMAKE_BUILD_TYPE “Debug”) - i.e. no leading D, so you are indeed not building in Debug.  When Ceres is built in Debug, you should see something like this appearing in the output from the CMake configure stage:

=================================================================================

-- Build type: Debug. Performance will be terrible!

-- Add -DCMAKE_BUILD_TYPE=Release to the CMake command line to get an optimized build.

=================================================================================

The use of the “-D” prefix (note the dash) is for when you are passing values on the command line to CMake, for example you could (and I would recommend it) instead of editing the CMakeLists, invoke CMake with:

cmake -DCMAKE_BUILD_TYPE=Debug <PATH_TO_SOURCE>

Be warned though, as we note here: http://ceres-solver.org/building.html#customizing-the-build - any variable set on the command line with -D overwrites any value that you set in the CMake GUI.

-Alex

P.S. You can use -D<VAR> in calls to add_definitions() in CMakeLists, but that is for a different purpose (namely adding compile definitions).

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CADpYijE-3TNRBSODEoQetErPmDgrwQ2HiD04i9OEi9QxSZsP8A%40mail.gmail.com.

[Rémi Cura]

Hey,
thanks for this,
I was really confused :-(
In fact I had tried to remove the "D", but it still wasn't giving more info.
I suspect it's because I should rebuild all ceres in debug (and not only my program).

I use the cmakelist because my (old) version of qtcreator it only proposes to use "make" .
Inspired by your tips, I changed it to first use cmake then make,
using the proposed arguments for debug or release.

Many thanks,
Rémi-C