Trouble with Trajectory Tracking | What is pieceOffset?

[jacobhiggins]

Hello,

I am using crazyswarm to track generated trajectories, and I've gotten the crazyflie to correctly track a single generated trajectory. To do this, I'm using the two ROS services provided by crazyswarm:

• uploadTrajectory
• startTrajectory

Using these services, I upload two different simple trajectories, one that moves the crazyflie forward and one that moves the crazyflie backwards.

I use uploadTrajectory to upload both, then I start one trajectory, wait until that trajectory is finished, and then start the second trajectory. Each trajectory is started with relative=True, so that the trajectory is always relative to the current position of the crazyflie.

The problem is that no matter what order the trajectories are uploaded in (forward then backward, or backward then forward), the crazyflie always crashes when tracking the second trajectory only.

The uploadTrajectory service has a pieceOffset parameter, which is an integer and looks like it has something to do with memory allocation, but isn't explained in the code or docs. When I change this pieceOffset, I see different behavior when the crazyflie tries to track the second trajectory, sometimes getting halfway through before crashing. This leads me to believe this might be a memory allocation issue.

I was wondering if anyone had an idea as to might be going wrong? Or at the very least, what the pieceOffset parameter does when allocating memory? Any ideas would be appreciated!

Best,
Jacob

[whoenig]

Each trajectory is described by 1 or more polynomials (rows in the csv file if you use that for uploading). If you want to upload multiple trajectories, the pieceoffset essentially describes the row you are referring to. So for the first trajectory the offset is 0, for the second it is the number of rows the first csv file had.

[jacobhiggins]

Thanks! Setting the pieceOffset seemed to work.

One follow up question: my project involves updating new and different trajectories every 1 second or so to the crazyflie. I noticed that even if I set the trajectoryId=0 for any trajectory I send it, I still need to set the pieceOffset according to your description above in order for the crazyflie to track the correct trajectory. For example, in my case every trajectory has 2 segments, so every time I send a trajectory I set:

• First trajectory: trajectoryId=0 & pieceOffset=0
• Second trajectory: trajectoryId=0 & pieceOffset=2
• Third trajectory: trajectoryId=0 & pieceOffset=4
• Etc.

If I constantly set pieceOffset=0 for any new trajectory, I again get the weird behavior where the crazyflie seems to track a completely different trajectory when it gets to the second trajectory.

I don't exactly mind constantly incrementing the pieceOffset, but I know it has to do with memory allocation, and worry that I might eventually run out of memory if the pieceOffset is too big.

I was wondering if you had suggestions on how to constantly update the current trajectory tracked by the ROS service? Or should changing the pieceOffset be okay in the long run?

Thanks again for the answer, I really appreciate it!

[whoenig]

You will run out of memory if you keep incrementing. I think the firmware has in total space for 20 pieces or so. In theory it should be possible to double/triple buffer, i.e. only replace a trajectory while you are certain that it is not in use. The issue with that approach is, that there is no guarantee how long a trajectory upload takes, since it requires ack's and packets might need to be resend. At the same time, Crazyswarm1 has no notion of packet priorities: if you use a motion capture, it is possible that the state updates are not send in a timely fashion during a trajectory upload causing crashes. In general, I'd recommend using cmdFullState and evaluating the trajectories on the host computer in your use case.

[jacobhiggins]

Thanks for the follow up reply! Sure, that makes sense. I'll switch to using cmdFullState for my project.

[asahin1]

Hello,

I had a related question to this. If I have a single trajectory consisting of multiple piecewise polynomials (a single csv file with multiple rows), is there a difference between the methods I listed below to follow this trajectory:

1. Use upload_trajectory to upload the trajectory and start_trajectory to follow through
2. Evaluate the trajectory at each time step on the host computer and send the corresponding commands using cmdFullState

I suppose in this case the memory and trajectory upload speed will not be an issue, since there is only a single trajectory (even if it contains a lot of pieces).

Thank you for your time.