Maximum number of polynomials in a Trajectory?

[mygo5]

I believe that I'm causing problems with my implementation by trying to upload a trajectory which has a large number of polynomials (~550). I'm currently pursing workarounds, but was wondering if there was knowledge on an upper limit so I can confirm this was the issue

[whoenig]

Almost certainly not that much, see https://github.com/bitcraze/crazyflie-firmware/blob/16c5630707e92830dcd16455a57b5560e5838735/src/modules/src/crtp_commander_high_level.c#L81-L84.

[mygo5]

Thanks! This helped a lot

I have a rather complex spline of 7th order polynomials that I've generated, which I'll call r(t). I've explored options of simplifying the trajectory which may or may be the route I go, but I wanted to look into creating a mid-level controller to track this trajectory (without needing to upload the massive thing directly to the cfs)

-I was thinking of using cmdVelocityWorld(vel, yawRate) with my r_dot (t) being used as the feedforward term and implementing a feedback component as well

-Alternatively, using cmdFullState(pos, vel, acc, yaw, omega) could be interesting. Omega is directly related to jerk which would give substantial control over the smoothness of the trajectory. I wasn't sure if CrazySwarm or CrazyFlie had this relationship explicitly formulated for the crazyFlie system anywhere, though

If an application of something like this, or any lessons learned of trying similar approaches is known, that would be great!

[whoenig]

We usually use cmdFullState in that case, see https://github.com/IMRCLab/crazyswarm2/blob/main/crazyflie_examples/crazyflie_examples/cmd_full_state.py for an example. This works well as long as you don't control more than 4 CFs (per radio), otherwise the on-board version is beneficial. Also, more aggressive maneuvers need the higher-orders (up to snap).