Bitcraze Forums

Hello,

I'm looking at adding an ultrasound sensor to the crazyflie to determine the height of the copter and enhancing the firmware to make use of this and hold an exact altitude. I want to get the copter to a specific height, then enable a "keep this altitude" functionality, and then let go of the thrust and just move the copter around with roll,pitch,yaw.

Using the prototyping board, I've succeeded in adding a sonar and using the Deck API I got the firmware to get sonar data and log it with the logging API.

Now I'm looking at the code to have the copter use that altitude information but I'm a bit confused on several things:

It seems there is already code for this, named "althold" that uses the barometer data. Enabling it however doesn't seem to work. When I enable it the copter will just slowly got to the ground and stop (I'm flying it indoors). Is this expected?

I see the position_controller is there to calculate attitude/thrust to approach a given 3d point. I can use that to set a z coordinate. But what is the "thrustBase" for?
To keep an altitude, I would expect that the mode is "modeAbs" with the "setpoint->position.z" set from when the "althold" mode is enabled. However, the mode is set to "modeVelocity":
Why is the velocity only set? Why is the "rawThrust" normalised like this?

Which brings me to my next question, what is exactly "modeVelocity" ?
And what does it mean in the context of the "setpoint_t" struct: what is the difference between setting a mode for x,y,z and for roll,pitch,yaw?

Thanks for your help, and sorry if I missed something obvious.

Perhaps I misunderstood what "althold" is.

What I'm going to do is modify the code to set the state position.z from the sonar directly and then set the setpoint position.z (and mode.z to modeAbs) and believe the position_controller should it's magic to keep the copter at the same height. Is this the correct approach?

Do you have any suggestion how to do this from the Deck API?

Thanks again.

Hi,

The Bitcraze experts can answer your questions far better than I can. However, I've been looking at some of the same things in the latest source code as you have and have come away with an albeit limited understanding, perhaps some flawed interpretations in certaine areas. I certainly don't want to add more confusion.

My understanding is that the altitude hold function uses a thrust method to set the desired altitude. ThrustBase is key to this and might have to be increased beyond the default when adding payload weight to the crasyflie. ModeVelocity (rate) instructs the pid controller to use rate aiding (or velocity * delta time) for changing the desired altitude and is the mechanism for the controller device to raise or lower the desired altitude (via the throttle stick). In formulating the actual altitude of the crazyflie, sensor fusion is employed and this includes inputs from the barometric pressure (altimeter) sensor. Baro.asl is not used to set the desired altitude, but is used to aid the measured altitude.

I assume that the baro.asl is not used to set the desired altitude because it is a bit noisy and also is affected by local air currents (pressure changes). Using a better sensor for setting the desired altitude certainly makes sense (then modeAbs permits position changes to be ussed). However, when setting mode to modeAbs it's not clear that the existing code supports a position (modeAbs) input at the same time as accepting a velocity (modeVelocity) input, e.g., from the controller device (thrust stick changes converted to velocity changes).

One explanation for the crazyflie to slowly go to ground while in altitude hold mode is that the thrustBase is too low. Another is a low battery voltage.

I apologize if I'm adding more confusion to your questions.

Best regards,
Jack