hi
I'm trying to develop functionality that mixes the push demo with manual control (remote control via cfclient) to basically "fly without crashing" (will not let you fly into obstacle)
so the "app" is currently sending setpoints, and they are overriding the remote control setpoints (I assume, tried using remote does not affect)
the goal is to superimpose the two. somewhere where the incoming setpoint is parsed. I know I can pass a value from the "app" to another place in the code via LOG variable. but hard to decipher where exactly the setpoint is parsed (also there are many types of setpoints, lets assume normal mode no assist)
do you have suggestions where I can start? thanks alot for your help and I can share the code for the result if anyone is interested.
flying without crashing!
Re: flying without crashing!
Hi!
Ah oke, this is maybe a bit of difficult one but a very interesting application! Are you also using a positioning system as well? So that you can use position setpoints from the app layer?
I believe that the setpoints for attitude control (which is normal just with the attidue) is done by the following function in crtp_commander_rpyt.c (https://github.com/bitcraze/crazyflie-f ... pyt.c#L119). It has a low commander priority (1), so if another command with an higher priority comes along, like from the app layer (3), it will not listen to the low priority anymore. Or at least that is my general understanding.
Just be aware of this issue we had a while ago: https://github.com/bitcraze/crazyflie-f ... issues/536. It should be fixed but its good to be aware.
Ah oke, this is maybe a bit of difficult one but a very interesting application! Are you also using a positioning system as well? So that you can use position setpoints from the app layer?
I believe that the setpoints for attitude control (which is normal just with the attidue) is done by the following function in crtp_commander_rpyt.c (https://github.com/bitcraze/crazyflie-f ... pyt.c#L119). It has a low commander priority (1), so if another command with an higher priority comes along, like from the app layer (3), it will not listen to the low priority anymore. Or at least that is my general understanding.
Just be aware of this issue we had a while ago: https://github.com/bitcraze/crazyflie-f ... issues/536. It should be fixed but its good to be aware.
Re: flying without crashing!
Thanks Kimberly!
I also noticed the priorities thing, right after posting... I initially thought I should have the "app" constantly sending setpoints (so the default state is that the drone is hovering) and then have the remote "take over" . for that, I changed the "app" setpoints to actually be zero (lower than 1..) but the drone pretty much crashed during takeoff. maybe zero is not valid.
having it the other way around might be possible, having the app send NO setpoints by default, and then send only if there is an obstacle near. I will try it, but that has some limitations , the app does not know your current speed , it will send a fixed value as a function of your distance to the obstacle, so going close to a wall at different speeds will generate "spike" in velocity. and not to mention your height must match perfectly to the theoretical height. So I will push (hehe) forward to MUXing.
I'm pulling the velFront, velSide values as a log variable in the crtpCommanderRpytDecodeSetpoint but seems to do nothing. furthermore, I also put a DEBUG_PRINT in the same function , and it still prints nothing, so maybe this function is not called?
Also forgot to mention I am using Zranger2. and multiranger (this is the stated requirement for the demo) So app setpoints are "Hover" type (pretty sure) and the using remote control with the client also defaults to "flight mode: Normal , Assist mode : Hover" (when detects you have a zranger I guess? didn't try removing)
So I tried putting a DEBUG_PRINT in crtp_commander_generic , in the functions that decode the - Z_distance setpoint , and the hover setpoint. currently no change in behavior and no printing to console at all. have no debug adapter so can't investigate further. The thing with so many types of setpoints is confusing. It's not really clear what kind of setpoint is being sent by cfclient... any ideas welcome!
I also noticed the priorities thing, right after posting... I initially thought I should have the "app" constantly sending setpoints (so the default state is that the drone is hovering) and then have the remote "take over" . for that, I changed the "app" setpoints to actually be zero (lower than 1..) but the drone pretty much crashed during takeoff. maybe zero is not valid.
having it the other way around might be possible, having the app send NO setpoints by default, and then send only if there is an obstacle near. I will try it, but that has some limitations , the app does not know your current speed , it will send a fixed value as a function of your distance to the obstacle, so going close to a wall at different speeds will generate "spike" in velocity. and not to mention your height must match perfectly to the theoretical height. So I will push (hehe) forward to MUXing.
I'm pulling the velFront, velSide values as a log variable in the crtpCommanderRpytDecodeSetpoint but seems to do nothing. furthermore, I also put a DEBUG_PRINT in the same function , and it still prints nothing, so maybe this function is not called?
Also forgot to mention I am using Zranger2. and multiranger (this is the stated requirement for the demo) So app setpoints are "Hover" type (pretty sure) and the using remote control with the client also defaults to "flight mode: Normal , Assist mode : Hover" (when detects you have a zranger I guess? didn't try removing)
So I tried putting a DEBUG_PRINT in crtp_commander_generic , in the functions that decode the - Z_distance setpoint , and the hover setpoint. currently no change in behavior and no printing to console at all. have no debug adapter so can't investigate further. The thing with so many types of setpoints is confusing. It's not really clear what kind of setpoint is being sent by cfclient... any ideas welcome!
Re: flying without crashing!
I think that 0 is indeed not valid (https://github.com/bitcraze/crazyflie-f ... nder.h#L38)
About crtpCommanderRpytDecodeSetpoint() not being called, it is interesting though that it doesn't. Have you tried of just holding the crazyflie in your hand and only giving it commands through the joystick.
If you are using the zranger, I'm not sure if hover is possible, only height hold (https://www.bitcraze.io/documentation/t ... nger-deck/). For hover you need an position estimate and without the motion sensor, there is not enough information to have a position estimate. There is only only an height estimate.
So if the height is fixed, all the movement in the horizontal plane has to be done by pitch and roll commands only.
Sounds like an challenging project though! But its a good topic to learn the platform for sure.
About crtpCommanderRpytDecodeSetpoint() not being called, it is interesting though that it doesn't. Have you tried of just holding the crazyflie in your hand and only giving it commands through the joystick.
If you are using the zranger, I'm not sure if hover is possible, only height hold (https://www.bitcraze.io/documentation/t ... nger-deck/). For hover you need an position estimate and without the motion sensor, there is not enough information to have a position estimate. There is only only an height estimate.
So if the height is fixed, all the movement in the horizontal plane has to be done by pitch and roll commands only.
Sounds like an challenging project though! But its a good topic to learn the platform for sure.
Re: flying without crashing!
thanks for the reply! I got confused I am using the Flow Deck not zranger2 - does it change anything?
also, I realized that using the "assist button" on the remote can affect the type of setpoint being sent --- will try again and report.
also, I realized that using the "assist button" on the remote can affect the type of setpoint being sent --- will try again and report.
Re: flying without crashing!
Yes 
with the flowdeck you can actually send position and velocity commands since it provides position estimates as well. Although I guess with the Zranger it could have worked as well but your assignment would have been much more difficult! I would say that this is much more easier.
Could you also use the controller (through a pythonscript with the cflib) to send velocity commands instead? Or to send values to the app layer through the parameters frame work? Maybe the latter would be the easiest since you could do all the logic in the app layer and not touch anything related of the rest of the firmware.
Maybe in general would be easier to first try everything out just in a python script with the cflib first, just to check if everything works. Its easier for development I think.
with the flowdeck you can actually send position and velocity commands since it provides position estimates as well. Although I guess with the Zranger it could have worked as well but your assignment would have been much more difficult! I would say that this is much more easier.Could you also use the controller (through a pythonscript with the cflib) to send velocity commands instead? Or to send values to the app layer through the parameters frame work? Maybe the latter would be the easiest since you could do all the logic in the app layer and not touch anything related of the rest of the firmware.
Maybe in general would be easier to first try everything out just in a python script with the cflib first, just to check if everything works. Its easier for development I think.
Re: flying without crashing!
OK the solution was to edit the decode hover setpoint function.
I pulled the avoidance velocities as log variables from the "app" code
the biggest "aha" was that the cfclient is sending completely different setpoint types when the "assist" button is pressed. so the code will work only when the assist is active, but you can still fly the drone without assist.
My CF is currently broken so I can't make a video but if anyone is interested I can write a tutorial soon
I pulled the avoidance velocities as log variables from the "app" code
the biggest "aha" was that the cfclient is sending completely different setpoint types when the "assist" button is pressed. so the code will work only when the assist is active, but you can still fly the drone without assist.
My CF is currently broken so I can't make a video but if anyone is interested I can write a tutorial soon