ProblemData usage is ambiguous

[echandler5956f]

My understanding is that we have an abstract ConstraintBuilder which is templatized by some <ProblemData> type.

Then, the user implements concrete ConstraintBuilder such as FrictionConeConstraintBuilder, which are also templatized by some <ProblemData> type (but we know ahead of time that that type will be a user-defined FrictionConeProblemData).

Then, the FrictionConeConstraintBuilder overrides the virtual ConstraintBuilder methods, and creates the ingredients to produce a ConstraintData.

Up to here, I think I understand.

What I do not understand is how we templatize TrajectoryOpt with some < ProblemData > type. I am assuming the intent is so that we can run the concrete xxxConstraintBuilder's from within TrajectoryOpt, so that the user does not have to. This would also be convenient for updating the ConstraintData. I imagine we have something like this pseudocode:

class LeggedRobotProblemData 
{
    GeneralProblemData;
    std::vector<ProblemDatas*> problem_data_vec = {FrictionConeProblemData, ContactProblemData}
}

traj_opt(LeggedRobotProblemData, std::vector<ConstraintBuilder> = {FrictionConeConstraintBuilder, ContactConstraintBuilder})

    in traj_opt:
    Gvec = {}
    i = 0
    for (auto &builder : builders)
    {
        builder->build_constraints(problem_data_vec[i]);
        Gvec.insert(builder->get_g());
        ++i
    }

However, there is not yet a base class which xxxSpecificProblemData's are derived from, so we cannot index them from a container within TrajectoryOpt. And if we do add a base class, other things begin to not make sense. Also, if we pass in a vector of * ConstraintBuilders, how do we know what type of ProblemData they are associated with? The more I play around with it, the more problems I run into.

How do we rectify this? At the end of the day, all we need is a vector of ConstraintData and some metadata about the current phase, but the current approach seems somewhat bloated and overcomplicated.

[echandler5956f]

As it turns out, if we just pass LeggedRobotData as the template argument, it makes perfect sense. See 1e9f2e0