Flying Crazyflie to a specific position setpoint

Discussions about all things Bitcraze
kimberly
Bitcraze
Posts: 252
Joined: Fri Jul 06, 2018 11:13 am

Re: Flying Crazyflie to a specific position setpoint

Post by kimberly » Mon Jan 27, 2020 11:40 am

So first the post about your makefile. I also noticed that your makefile has the Kalman estimator forced (ESTIMATOR: Estimator type forced). So there are probably more things going on so you probably need to check in your makefile how it differs from master.

You know that, instead of changing of changing the makefile, you can also add a file called config.mk (tools/make/), and add those defines in there? Might be handy to separate things.

Second post
1. Then you can observe the state estimates of the position, which means logging the following variables: kalman.stateX,stateY,stateZ (you can check in this file how this is setup https://github.com/bitcraze/crazyflie-f ... r_kalman.c). You can then use the functions here if you put 'log.h' in the header to access those variables: https://github.com/bitcraze/crazyflie-f ... /log.h#L37. These are probably the inbuild messaging system you are looking for?
2. With the above inbuild functions, you do not need an external variable to share the data.

If you wish to keep you work on the firmware separate, read up about our new applayer functionality: https://www.bitcraze.io/2019/10/app-lay ... unication/. This would be perfect to keep your application separate from the code.



nicuvlad94
Beginner
Posts: 15
Joined: Sun Sep 08, 2019 12:44 pm
Contact:

Re: Flying Crazyflie to a specific position setpoint

Post by nicuvlad94 » Mon Jan 27, 2020 12:36 pm

Thank you for your answer! Yes, I knew about this so I put my additions in tools/make/config.mk:

Code: Select all

ESTIMATOR = kalman
CFLAGS += -DDECK_FORCE=vlad
Does it make any difference if I force the estimator to Kalman? I thought it is anyway the default one.

kimberly
Bitcraze
Posts: 252
Joined: Fri Jul 06, 2018 11:13 am

Re: Flying Crazyflie to a specific position setpoint

Post by kimberly » Mon Jan 27, 2020 12:45 pm

Actually, the complementary filter is the default one, except if certain deck are being activated for positioning. Check out this blogpost if you want to know more about it :) https://www.bitcraze.io/2020/01/state-e ... not-to-be/

nicuvlad94
Beginner
Posts: 15
Joined: Sun Sep 08, 2019 12:44 pm
Contact:

Re: Flying Crazyflie to a specific position setpoint

Post by nicuvlad94 » Mon Jan 27, 2020 12:56 pm

I understand. But as long as I am using the flow deck, the Kalman estimator is the way to go for me. Talking about estimators, I would have a question about the initialization of the estimator. Basically, what is the zero degrees yaw position? Is it the axis pointing to North, or it is just the position in which drone finds itself at startup? Or it is the yaw value from takeoff...

Because something strange happens: I align the drone in one position, and then I turn it on and I command a setpoint with: (x=0, y=0, z=1, yaw=0). The drone takes off, but because the floor is not very smooth (a carpet) yaw drifts around 45 deg. And it stays like that, so basically thinks that the zero deg yaw is the position in which it drifted.

Is this because magnetometer signal is weak indoors? Or because the initial value of the estimator is reset after takeoff?

Thank you!
Vlad

kimberly
Bitcraze
Posts: 252
Joined: Fri Jul 06, 2018 11:13 am

Re: Flying Crazyflie to a specific position setpoint

Post by kimberly » Mon Jan 27, 2020 1:05 pm

It is the position where the drone finds itself at startup. For the kalmanfilter we are not using the magnetometer input at all, so it is all based on its gyros (so angle rate).

Unfortunately, it seems that if the crazyflie is on the ground for a while, the yaw drifts more than usual than in the air. So while it's on the ground, the yaw estimate has drifted to -45 degrees, then the crazyflie takes off and wants to put this to 0 and moves itself 45 degrees.

Best way is to either reset the estimator right before taking off, or assign the yaw controller to be controlled in modeVelocity instead of position mode (so it does not want to actively go to 0 again.

nicuvlad94
Beginner
Posts: 15
Joined: Sun Sep 08, 2019 12:44 pm
Contact:

Re: Flying Crazyflie to a specific position setpoint

Post by nicuvlad94 » Mon Jan 27, 2020 1:13 pm

Ok. This is unexpected, maybe a debias of the gyro would help. I am not sure if crazyflie has it: i.e. leave the drone on flat ground for a few seconds and perform the average of the measured angular velocities. Then, substract these values from any future measurement. Is such thing implemented in CF?

And a last question: What does exactly the DEBUG flag do. What happens when it is set to 1 and why is the compiled program way bigger then?

Thank you!
Vlad

kristoffer
Bitcraze
Posts: 207
Joined: Tue Jun 30, 2015 7:47 am

Re: Flying Crazyflie to a specific position setpoint

Post by kristoffer » Thu Jan 30, 2020 9:52 am

The gyro bias is measured during the startup sequence, but not after that.

The DEBUG enables some extra logging and checking, and it also disables the watch dog.
The main reason that the binary is larger is that the size optimization in the compiler is turned off to make debugging easier.
See https://github.com/bitcraze/crazyflie-f ... #L271-L278

You mentioned earlier that you got a crash
It seems that having debug mode on ("DEBUG=1 in the makefile") crashes the drone while flying.
If you have found a problem that you can reproduce, please add an issue to github https://github.com/bitcraze/crazyflie-firmware/issues

nicuvlad94
Beginner
Posts: 15
Joined: Sun Sep 08, 2019 12:44 pm
Contact:

Re: Flying Crazyflie to a specific position setpoint

Post by nicuvlad94 » Fri Jan 31, 2020 2:31 pm

Thank you! I will post my issue soon!

I still have some further questions: Setting x,y,z to modeDisable is equivalent to running the drone in attitude mode (where also flow deck is not used?)
I tried to put x and y to modeAbs and z to modeVelocity. And then I commanded a setpoint of (0,0,0). In this case, I would expect that CF keeps the (0,0) position, while the altitude is not regulated (i.e. I should be able to lift and push on the drone and it should keep its x and y). I am asking that because I am interested in launching the drone from my hand. So I want to leave it on the ground to calibrate and and lift it and when I perform a specific gesture, drone should take off.

Thank you!
Vlad

kimberly
Bitcraze
Posts: 252
Joined: Fri Jul 06, 2018 11:13 am

Re: Flying Crazyflie to a specific position setpoint

Post by kimberly » Mon Feb 03, 2020 11:09 am

Yes, if x, y, z is set to disabled and roll/pitch is set to modeAbs and yaw to modeVel, that is equivalent to attitude mode.

So it seems that what you are trying to do should work, But I must say, this will work only as long if you are using an external positioning system and not the flowdeck. The surface of the hand is too small for the crazyflie to get a good height estimate so it will go up and down a lot... Trust me, I tried this before :)


Take also a look at this github issue (https://github.com/bitcraze/crazyflie-f ... issues/540), this might be also something that needs to be fixed before we can get this to work.

nicuvlad94
Beginner
Posts: 15
Joined: Sun Sep 08, 2019 12:44 pm
Contact:

Re: Flying Crazyflie to a specific position setpoint

Post by nicuvlad94 » Mon Feb 03, 2020 12:25 pm

Thank you for your reply! I will try the attitude mode as you suggested (because in my setup I also kept x and y to modeAbs). Also, for the hand release, I will try at least to hold it from the upper side, because I am using a self-developed shield at the moment and this gives me some "handler".

I think it makes sense for altitude control. Without proper feedback for z, it is hard to maintain the position. I hoped that the cross-couplings from x and y can help.

One curiosity: Why do you make the gyro debias mandatory whenever drone boots? I think STM32 has some flash registers so you can write stuff there which stays also after shut down. So wouldn't make more sense to have a logic like this:
- if debias was performed in the past and drone is steady, redo the debias
- if debias was performed in the past and drone is not steady, boot with the last debias params
- if debias was not performed in the past and drone is not steady, don't boot

Not sure if this makes sense, but it just came into my mind :D

Thank you!
Vlad

Post Reply