Non null thrust on connect

[overdrivr]

Hi everyone,

When I connected to my crazyflie for the first time, the thrust was not zero causing the crazyflie to go straight to the ceiling. I don't have a ps3 controller yet, is it *normal* behavior in the absence of a controller ? Maybe it is because since there is no controller, the controller does not receives commands, and tries to level, believing the radio is lost...

Note : I just tried reconnecting it (and strapped it to some weight) and it doesn't exhibit this behavior anymore, motors are off, hope I didn't break anything on first flight.

Any similar experiences on that topic ?

[marcus]

Hi,

Are you running the client in a virtual machine? If so, then you might be seeing the problem described here. When no joystick is passed to the VM some kind of virtual input device is used. The one that is present in VirtualBox will give input depending on where the mouse pointer is on the screen. Next time you connect to your Crazyflie make sure to look in the bottom left corner of the client window at what device you are using and also make sure that the thrust is not set before you connect.

/Marcus

[rmirwin2]

Seems like a potential safety issue. On connect, why should a non-null value for thrust be permitted? On connection, wouldn't it be better to zero the value and throw a warning to the user before allowing a fly-away? Or even some kind of general "safety interlock" on the controller to ensure the user is ready to apply thrust after powering up? Could prevent damage/harm when an error is made or a controller is picked up inappropriately. Just a thought.

[overdrivr]

You're right marcus, it's the "mouse pointer" thing. I remember to be surprised to see the thrust bar not at zero when I connected for the first time, well now I understand what happened.
I am not familiar with python, but maybe the killswitch for the engines could be activated on client startup. Well I'll give it a try & pull back the changes if I find it.


Great job with that quadcopter anyway... Quite robust after seeing how it withstanded the first crashes

[marcus]

Yes, this is bad. We have been talking about two different solutions for this, but none of them are implemented yet.

• Arming mechanism: In order to send commands to the Crazyflie you would have to first set full thrust and then zero. After this the client will start sending commands to the Crazyflie.
• Blacklisting: Blacklist any input-devices that are named *Virtual* etc.

Which one do you think would be the best? Or maybe both?

[Surrender]

The arming mechanism would be great.

I've found a article from Arducopter where the dis- and arming is described: http://code.google.com/p/arducopter/wiki/AC2_Flying

Here the important part copied from this page:

Arming is done by applying Full-Right Yaw and No Throttle. On a Mode 2 transmitter, this means the left stick would be Down and to the Right. On Mode 1, the means the the right stick must be Down and the left stick Full-Right.
When the motors are armed, the green LED will turn solid.
Disarming is done by doing the reverse: applying Full-Left Yaw and No Throttle. On a Mode 2 transmitter, this means the left stick would be Down and to the Left.
Both the arming and disarming positions need to be held for a few seconds. This is a safety mechanism to prevent accidental disarming during flight and accidental arming during transportation.

This procedure can also be used with a XBox or PS3 controller.

[marcus]

Thanks for the tip. I've been thinking about this and wondering how it would fit with the "Emergency stop" that we currently have as well. For new users there's suddenly a number of issues that might prevent the Crazyflie from working as expected.

What about renaming the "emergency stop" to "arming" and setting it disabled by default? This way you can easily "de-arm" the Crazyflie while in flight. If users don't have the extra button or don't want to bother about the arming procedure we can add an option in the UI to disable it (or at least set it to armed by default).

[rmirwin2]

Hello Marcus,

I like your thought, set the current "Emergency Stop" to On, requiring "Arm" button press before thrust can be applied. That would be a significant improvement and one that could rapidly be deployed if connection is lost during flight. Even so, if you pick up the controller wrong, it would still be possible to energize the motors.

Maybe push "Emergency Stop" and then "Arm" buttons in sequence to energize? That meets muster as far as I'm concerned and is easy to remember.

I don't like having to push to "full throttle" and then "zero throttle" to enable thrust because it assumes the Crazyflie is in some state. Pushing to full throttle could lead to an abrupt take-off if the Crazyflie was already connected.

From what I remember my DX-7 requires that you pull down the throttle from a non-zero position to zero and then provides an audible tone when thrust is available. That's okay too. In that case, just pull the stick to zero for a few seconds.

Either way, perhaps the Crazyflie could maybe make some tone using the motors when the motors are first enabled!

Keep up the great work!
Rich

[Surrender]

I've developed a sound making routine, it is played when CF is switched on. See "[New Feature] Start-up Melody"


Sent from my GT-I9100 using Tapatalk 4 Beta

[Shuriken]

I was having a hard enough time just getting it to work...even without a VM. Funny but after looking at a lot of videos before I bought the CF I was EXPECTING an arm/disarm mechanizm but couldn't find it in the literature. Now I know why. BTW. My biggest problem was finding the line that says "select the radio". I could have said..."select 'Connect' from the CF console. Then when the 'Connect Crazyflie' window appears select/highlight the 'radio' line and then select 'Connect' in the bottom right of the window'" I think this information should be prominent in the startup instructions...IMHO.