Why is multi-threaded spinner not used?

[shubham-shahh]

Hi @bigsuperZZZX, I am using the planner with point cloud data and I get this error again and again [traj_server] Lost heartbeat from the planner, is it dead?

to get around this error, I used a multi-threaded spinner, which lead to the following error A negtive value of nearby obstacle number! reset the map.

can you point out possible solutions to tackle the problem of heartbeat?

[shubham-shahh]

Hi @bigsuperZZZX , Any update on this?

[bigsuperZZZX]

Please do NOT use a multi-threaded spinner, it will cause many unexpected problems.

[shubham-shahh]

Please do NOT use a multi-threaded spinner, it will cause many unexpected problems.

Yes, i have encountered them, mostly i noticed a lot of segmentation faults in optimization section. but callbacks such as fading callback and cloud callback ( In my case I'm using a point cloud) take a lot of time to execute changeinBuf function which reduces the rate at which the FSM timed callback is running

Can you point out potential solutions to overcome this problem

Thanks

[shubham-shahh]

Hi @bigsuperZZZX, any update on this?

[bigsuperZZZX]

It requires a lot of mutexes and seems to be a big project.

[shubham-shahh]

For a single drone executions, what all places would need mutex? I think a mutex between fading callback and the update cloud callback

And in the plan manager, for state machine callback and check collision callback, please correct me if i am wrong and please add if more mutexes are needed

Thanks

[bigsuperZZZX]

It also requires a mutex between the planning callback and the mapping thread.

[shubham-shahh]

It also requires a mutex between the planning callback and the mapping thread.

I see, if I understand correctly, the getInflateOccupancy() and the changeIngBuf() functions need to work in mutex such that, when the map is being updated, it cannot be accessed by the planner and vice versa.

please correct me if I am wrong and please add if more precautions are needed

[bigsuperZZZX]

That's true.

[shubham-shahh]

That's true.

for a swarm configuration, do I need to run RecvBroadcastMINCOTrajCallback() in mutex with any other function?

[bigsuperZZZX]

Yes, when computing a new trajectory, the buffer storing others' trajectories should not be changed.

[shubham-shahh]

Yes, when computing a new trajectory, the buffer storing others' trajectories should not be changed.

got it, that makes sense, I'll look into it thanks once again for the help. I'll close this for now, and post if I have any updates

thanks