Feature Request
Summary
C3 should be usable as a drop-in replacement for any MPC controller. When contact parameters are not provided, C3 should fall back to standard MPC rather than failing. This would make C3 a strict generalization of MPC — capable of handling both contact-implicit and contact-free problems under a single unified interface.
Current Behavior
The current architecture assumes contact parameters are always present and fails if they are not specified. This forces users to maintain a separate MPC controller for tasks that don't require contact-implicit planning, even though C3 should theoretically subsume that use case.
Desired Behavior
- If contact parameters are not provided, C3 automatically reduces to a standard MPC solve.
- No additional flags or configuration should be required — the absence of contact parameters is itself the signal.
- A warning or log message indicating MPC-only mode would be helpful for transparency.
- Long-term, C3 should be usable as the sole controller regardless of whether contact reasoning is needed, eliminating the need to maintain parallel MPC infrastructure.
Motivation
C3 is a generalization of MPC. There should be no task for which one would reach for a standalone MPC controller instead of C3 — if contact is not relevant, C3 should simply behave like MPC. The current hard failure when contact parameters are absent prevents this unification and forces unnecessary architectural complexity on downstream users.
Benefits
- C3 becomes a true superset of MPC, with no need for parallel controller infrastructure
- Removes a hard failure mode in the current architecture
- Simpler onboarding: users can start with no contact parameters and add them incrementally as needed
Feature Request
Summary
C3 should be usable as a drop-in replacement for any MPC controller. When contact parameters are not provided, C3 should fall back to standard MPC rather than failing. This would make C3 a strict generalization of MPC — capable of handling both contact-implicit and contact-free problems under a single unified interface.
Current Behavior
The current architecture assumes contact parameters are always present and fails if they are not specified. This forces users to maintain a separate MPC controller for tasks that don't require contact-implicit planning, even though C3 should theoretically subsume that use case.
Desired Behavior
Motivation
C3 is a generalization of MPC. There should be no task for which one would reach for a standalone MPC controller instead of C3 — if contact is not relevant, C3 should simply behave like MPC. The current hard failure when contact parameters are absent prevents this unification and forces unnecessary architectural complexity on downstream users.
Benefits