Page 1 of 1

the goals is a flip

Posted: Mon Oct 29, 2018 4:08 pm
by Davidefinocchi
Hi, i'm using a crazyflie 2.0 for the first time, the goals of my project is to make a flip, anyway i don't know how to start my project and how can i better undestand the code?
i undestood that to communicate with the drone i have to write a script in python where i use the cflib, but for a maneuver like flip i think the pid is not enough.
which control alghoritm is better to do a flip? Are there any firmware where the algorithm is just implemented?
Or is better make a script in python where there are control and trajectories?
Hope in some usefull suggestion or some code to try and better undestand the code.
Thanks

Re: the goals is a flip

Posted: Tue Oct 30, 2018 2:32 pm
by arnaud
Hi, you most likely will need to work in the firmware since you need to control the Crazyflie in rate mode to achieve a flip and you most likely need to react quickly to the change of attitude (ie, enable rate mode, flip, reenable absolute mode when the angle of the platform is flat enough).

You can look at the paper from USC from Crazyflie 1.0 in the research portal: https://www.bitcraze.io/research/#publi ... azyflie-10. It describes making the Crazyflie 1.0 flip 1, 2 and three times. The same principle could be applied to Crazyflie 2.0, though the thrust margin is a bit lower on Crazyflie 2.0 so 3 flip might not be possible to achieve.

Re: the goals is a flip

Posted: Wed Nov 07, 2018 9:23 am
by Davidefinocchi
i notice that when the drone go head down the motors shut-off, i want to try to disable this limitation, cause i found a trajectory that can be feasble by pid. It is possible to do it?

Re: the goals is a flip

Posted: Thu Nov 08, 2018 7:51 am
by arnaud
This is implemented there: https://github.com/bitcraze/crazyflie-f ... #L135-L141. If you comment this code out, it should disable the behavior.

Re: the goals is a flip

Posted: Mon Nov 12, 2018 2:36 pm
by Davidefinocchi
I have another question, to control the drone during the flip, the controller use angular velocity and angular accelleration, it is possible obtain tha angular accelleration by cf client, with the logger or have i to do a descrete derivative of angular velocity?

Re: the goals is a flip

Posted: Mon Nov 12, 2018 3:00 pm
by arnaud
I do not think angular acceleration is something we estimate in the Crazyflie: the gyroscope gives us a reading in angular velocity. So you will need to estimate it yourself either on the ground or on the Crazyflie.

Re: the goals is a flip

Posted: Thu Dec 06, 2018 9:46 am
by Davidefinocchi
we notice that we can't send a angular velocity packet type to quadcopter, it is possible to implement that on firmware modifying the decoder function in crtp_commander_generic? and the controller is able to compute this type of packet or we have to modify the PID controller?
If exist a code where is implemented which i'm asking please link me to that. thaks

Re: the goals is a flip

Posted: Thu Dec 06, 2018 9:56 am
by arnaud
crtp_commander_generic is the right place to implement a velocity setpoint packet. The PID controller should already handle it fine since it has been previously implemented using the rpy controller packet. I do not know of any existing implementation but it should be pretty easy to add the new packet type by looking at the other packet implementation as examples.

Re: the goals is a flip

Posted: Fri Jan 11, 2019 9:22 am
by Davidefinocchi
we have implemented a packet like explained in the crtp_commander_generic , following the suggestion of the file, but when we send a packet from python file, the firmware doesen't work, looks like the firmware lost the data, i attach the code in use. have you some suggestions?

Firmware code:

Code: Select all

typedef void (*packetDecoder_t)(setpoint_t *setpoint, uint8_t type, const void *data, size_t datalen);

/* ---===== 1 - packetType_e enum =====--- */
enum packet_type {
  stopType          = 0,
  velocityWorldType = 1,
  zDistanceType     = 2,
  cppmEmuType       = 3,
  altHoldType       = 4,
  hoverType         = 5,
  fullStateType     = 6,
  positionType      = 7,
  angularVelocityType = 8,
};
/... there are other packet.../
struct angularVelocityPacket_s {
	float rateRoll;
	float ratePitch;
	float rateYaw;
	uint16_t thrust;
} __attribute__((packed));
static void angularVelocityDecoder(setpoint_t *setpoint, uint8_t type, const void *data, size_t datalen)
{
	const struct angularVelocityPacket_s *values = data;

	ASSERT(datalen == sizeof(struct angularVelocityPacket_s));

setpoint->mode.roll = modeVelocity;
	setpoint->mode.pitch = modeVelocity;
	setpoint->mode.yaw = modeVelocity;

	float const millirad2deg = 180.0f / ((float)M_PI * 1000.0f);
	setpoint->attitudeRate.roll = millirad2deg * values->rateRoll;
	setpoint->attitudeRate.pitch = millirad2deg * values->ratePitch;
	setpoint->attitudeRate.yaw = millirad2deg * values->rateYaw;

	setpoint->thrust = values->thrust;
}
/* ---===== 3 - packetDecoders array =====--- */
const static packetDecoder_t packetDecoders[] = {
  [stopType]          = stopDecoder,
  [velocityWorldType] = velocityDecoder,
  [zDistanceType]     = zDistanceDecoder,
  [cppmEmuType]       = cppmEmuDecoder,
  [altHoldType]       = altHoldDecoder,
  [hoverType]         = hoverDecoder,
  [fullStateType]     = fullStateDecoder,
  [positionType]      = positionDecoder,
  [angularVelocityType] = angularVelocityDecoder,
};


PYthon code:

Code: Select all

def send_angular_velocity_setpoint(self, rollrate, pitchrate, yawrate, thrust):
        """
        -
        """
        pk = CRTPPacket()
        pk.port = CRTPPort.COMMANDER_GENERIC
        pk.data = struct.pack('<BfffH', 8, rollrate, pitchrate, yawrate, thrust)
        self._cf.send_packet(pk)