Final testing with the full system calibration of both cars.

I'm getting this and other similar conversion errors when trying to build under 32-bit Ubuntu. I'm running 12.04 LTS.

.../src/aslam_incremental_calibration/incremental_calibration/src/algorithms/marginalize.cpp: In function ‘Eigen::MatrixXd aslam::calibration::marginalJacobian(cholmod_sparse*, cholmod_sparse*, cholmod_common*)’: 
.../src/aslam_incremental_calibration/incremental_calibration/src/algorithms/marginalize.cpp:74:45: error: invalid conversion from ‘std::ptrdiff_t* {aka int*}’ to ‘long int*’ [-fpermissive]

Is the estimator using some kind of trust-region method? It prints out a lambda (like Levenberg-Marquardt) but I don't think it is using that. Is it using a trust region method? If the objective function has a regression, will it catch that? We should implement the DogLeg algorithm.

I shouldn't be calling the code this way, but the optimizer shouldn't crash in any case. I'm not sure if this is a problem with the incremental calibrator or the optimizer but it should be fixed at the most fundamental place (probably, now that I think about it, the optimizer).

Implement code that extracts the null space from a QR decomposition. It's a great tool for monitoring the observability of a problem.

Investigate the setting of the QR threshold and automate that. Play with the simple 2D-LRF example and try to see how the noise relates to it.

@HannesSommer
Do you know the thoughts behind using long types for the indices of sparse matrix elements in the linear solver/aslam?

I'm seeing this here during camera calibration. A new image comes in...it runs the estimation...the image isn't accepted because of the MI threshold, but the estimate is remains what it converged to during the test. This is especially important to avoid problems when bad batches enter the picture.

So, again, I'm doing everything wrong here but it is nice to find problems by calling all the functions wrong.

So: I had situations where the optimization did not converge but the incremental calibration selected the batch anyway. This will probably ruin everything! Can we detect convergence failure?

I'm working on the camera calibration problem. Right now I can't tell how to figure out what the outcome was of adding a batch. Did the estimator accept the batch or not? Are there other pieces of information we want to return here? For example, I would probably like to see the mi improvement even if the batch was rejected.

Jerome,
What happens if someone builds an OptimizationProblem and assigns a design variable (let's call it DVA) to group 0, then adds it to the IncrementalOptimizationProblem.

Then they create another OptimizationProblem with DVA added to group 1.

Does your code detect the error?

Thanks!

A more thorough analysis about the MI threshold, investigate if measurement sequence plays a role.

Develop an odometry block for the Toyota PRIUS (also suitable for other cars).

Using Applanix navigation solution, Applanix DMI, CAN front and rear wheel speeds, CAN steering, calibrate the car and inspect returned values.

Optimize the ordering for the covariance recovery. Here the idea is to first let the QR algorithm run and pick up the ordering it chooses.

Does the covariance recovery really use the full inverse? Or the pseudo inverse? What happens when it is really singular?

Write codes in aslam_simulation for generating odometry measurements

On the 2D-LRF problem, inspect the basis for the null space.

simulate GPS measurements in aslam_simulation

This repository is about to go public.