obstacle avoidance integration into collision_avoidance

[boomer319]

Hello,

I am working with a swarm of 8 crazyflies, each with an AI deck.

Optical flow extracted using NanoFlowNet is used to estimate where obstacles could be in the field of view of the AI deck camera.

A simple waypoint mission is executed using crazyswarm2's goTo().
The collision avoidance built into the crazyflie is used.
Obstacles shall be avoided going from one point to the next.

I want to achieve obstacle avoidance by imitating another crazyflie where the obstacle is, triggering collision avoidance.
This approach eliminates any conflicts between the setpoint altering of the collision avoidance and other setpoints being published by a separate obstacle avoidance (as seen in this discussion).

I looked at this conversation between @whoenig, @jpreiss and @krichardsson.
Some time has passed though.
I want to find out what still applies.

I want to pose some questions based on what I am planning to do on a lower level:

1. Converting the output of the AI deck (basically an angle from the cf's heading) to an obstacle position.

• crtp_localization_service.h was mentioned for getting the position of the other crazyflies, but:
• Where can I get the pose of the crazyflie itself from? ourPos?
• Where can the position be extracted outside of collision avoidance?

2. Feeding the position of the obstacle into the collision avoidance.

• Doing nOthers++ and adding the position to otherPositions (around here) should do it? This would not be very elegant though.
• What is collision avoidance fed by upstream?
• When is collision avoidance normally accessed by the crazyflie? Everytime a setpoint exits the commander (as proposed here)?

Best regards

[knmcguire]

Hi! Let me try to help out here:
1-

• crtp_localization_services.h is mentioned as that is actually the code that handles the receiving of the position of the crazyflie as measured by external positioning systems. If this is done by monocast (crazyradio <-> 1 crazyflie), then the crazyflie receives only it's own pose by the external mocap system. Crazyswarm supportst broadcast (crazyradio <-> multiple crazyflie), so the packet send is not only for just on 1 crazyflie but for them all, meaning that it will contain the position of all the crazyflies that the broadcast is meant for. In that situation, all crazyflies will receive the positions of everyone but it filters out it's own (see here). This is then pushed to the state estimator to update the cfs own estimate of it's position. The other's position gets send to peerLocalizationTellPosition(item->id, &ext_pos);
• Yes ourPos gets it from state->position which is the exact place where the crazyflie's position estimates are.
• If you are going to use the stabilizer.c loop, then getting the state variable in your function is enough to get the state estimate of your crazyflie, as long as it is after this function stateEstimator(&state, stabilizerStep);. If you want to use something outside of the stabilizer loop, like the app layer, then you can use the internal log/param system to grab values from the stateEstimate values.
  2-
• You could do that, but yes I agree that is not very elegant. You should look perhaps to this function instead: void collisionAvoidanceUpdateSetpoint(. As you can see it gets the other crazyflies' position through this function. You should append it here with positions of your collision avoidance.
• I need to check this out because I'm not sure what they mean with upstream... perhaps they talk about an offboard controller? I'll need to double-check this.
• Not exactly sure what you mean with accesses either, but the location of the collision avoidance is entered in the stabilization loop here, which means that first the estimator runs, than the setpoint is received (from the queue that results from the crtp loop), then the supervisor checks out the current situation, and then the collision function modifies the setpoint. This is where the collision avoidance is accessed before it goes into the controller. So technically the commander has already set the setpoint before collision avoidance in terms of position setting or trajectory control .

[boomer319]

This was well needed.

With upstream I referred to the metaphorical river of data. You answered it nonetheless. Same with the accessing-question (when is the actual collision avoidance code used by the crazyflie).

Thanks a lot!!!

[knmcguire]

Ah great it clarified things for you :) !