Working with 2 analog axis (and + digital axis) controllers: is it possible?

[burakyueksel]

Hi,

Although the bitcraze webpage explicitly says that you need to have a controller (gamepad) with at leas 4 analog axis controller [1], I was wondering if anyone of you have managed to fly with controllers like this [2]:

What I like to do:

• Reduce the BOM of a crazyflie setup. Also I want to make the option of replacing gamepad cheper.
• In the picture above I imagine assigning the left side located 2 analog axis to e.g. thrust and yaw, and left digital axes to roll and pitch (blue/yellow button for pitch and green/red for roll).
• I would assign the max/min roll and pitch commands to those colors
• Alternatively, I would swap thrust/yaw with roll/pitch, simply because thrust and yaw are rather rate command/position(or angle) hold, unlike roll and pitch (angle command/hold).

What did I do so far:

• cfclient recognizes a gamepad like that directly (unlike my problems with PS3 controller on Ubuntu 22.04.2, see [3]).
• However I cannot assign colorful buttons to roll or pitch, because they are not analog. Cfclient explicitly asks for analog.
• I have assigned those buttons to the roll and pitch trim, and I see in cfclient that they are changed. But from the behavior of drone I do not see that the setpoints for roll and pitch are changing at all.

I have not compiled cfclient from the source, I assume somewhere there I need to change something and recompile :).

Can anyone help me for that?

Ah my motivation:

• I live in Tübingen.
• There is an awesome initiative from city, which creates space for all people for learning robotics, AI, etc: https://ki-maker.space/ (sorry, the page is in German).
• I like to use the awesome, light-weight, easy to crash/replace parts setup for teaching people how to program small robots and make them fly! It is really suited for it well, and perfect setup for indoor teaching.
• Especially for younger generation!
• But buying rather expensive controllers (I know cheaper than a cf 2.1, but still) is kinda blocking that idea: it is not scaling up.
• If I am successful, and if people like it, city might pay for more "crazyflie bundles". Disclaimer: I do not know if that happens. I am putting my time completely voluntarily, whenever I can create some minutes.

Maybe I am trying something wrong, and there is out there robust and cheap working gamepads?

I appreciate your feedback!

Note: I had worked with crazyflie back in 2012. Amazing to get one again!!

[1] https://www.bitcraze.io/documentation/repository/crazyflie-clients-python/master/userguides/userguide_client/#create-new-mappings

[2] https://www.reichelt.de/de/de/raspberry-pi-controller-snes-design-rpi-ctrlr-snes-p211468.html?PROVID=2788&gclid=CjwKCAiAxvGfBhB-EiwAMPakqo9onREeLAYQwUKXRMPMha-aZd475QPCojFY_cj1DBCOb1TkdFzLuhoCAHMQAvD_BwE&&r=1

[3] https://github.com/orgs/bitcraze/discussions/576

[krichardsson]

Hi,
I don't think there is any support for what you want to do, but it can probably be added. I'm not sure about the details and how to do it, but I like your goal and motivation!
I'll try to help you get started if you want to make a contribution. If you are not interested in contributing, I'm afraid all we can do at this point is to add it as an issue in the repo for possible future work.

I would assign the max/min roll and pitch commands to those colors

I think max roll/pitch would be a bit violent with the default settings, but as the user can tune it down in the client, it could work.

Maybe I am trying something wrong, and there is out there robust and cheap working gamepads?

I usually use the PS3 gamepad as it has pretty nice sticks, some other people in the office us pads from https://www.8bitdo.com/
None of them is very cheap though.

I have not compiled cfclient from the source, I assume somewhere there I need to change something and recompile :).

The client is written in python so there is no need to compile anything, just clone the code and run. There are instructions in the repo if you want to try.

I think the gamepad handling mainly is implemented in the input directory. Unfortenately I also have a recollection that it might be a bit messy... I hope you speak python fluently :-)

inputreaderinterface.py is probably the focuspoint. You can search the code base for helper.inputDeviceReader to find where it is called/used.

This is a start, let us know if you need help or want more information.

[burakyueksel]

Awesome 💛!
I will dig in whenever I can :)

[burakyueksel]

Still could not find the time for it, but I have looked ad the code: I can do something dirty in the first attempt :). Looking forward to some free time, then will update here, open issue, link to PR, etc.

Some observations, somewhat related to this discussion (I do not want to spam the discussion board with new stuff) @krichardsson:

• In my setup I only have crazyflie 2.1 (no additional decks), gamepad, and the crazyradio PA.
• Seen in cfclient, in "Normal" or in "Advanced" flight mode, I see "Position hold" and "Altitude hold" assist modes active, others ("height hold" and "hover") are grayed out.
• "Position hold" works like what I would call altitude or height hold, meaning it stabilizes the height given that it only has baro + imu. "Altitude hold" works like my thrust command is going to the collective thrust demand of the controller without a loop (maybe g-control, but definitely no loop for altitude/vertical position).
• Trim function works in "Normal" or in "Advanced" flight mode, when "Altitude hold" is selected. It is hard to control the drone.
• Trim function does not work neither in "Normal" nor in "Advanced" flight mode, when "Position hold" is selected. I see the trim parameters are changing in cfclient as I click the buttons, but no change in drone attitude.

I have taken out the trim commands from here

https://github.com/bitcraze/crazyflie-clients-python/blob/master/src/cfclient/utils/input/__init__.py#L478 up to L489 outside of the else and have put before this line https://github.com/bitcraze/crazyflie-clients-python/blob/master/src/cfclient/utils/input/__init__.py#L444, which did not do the trick I was hoping for: being able to trim pitch and roll with buttons while holding the altitude/height/z position :).

Any opinions on that?

Cheers,
Burak

[krichardsson]

I can do something dirty in the first attempt

Dirty is a good start :-)

The code you are looking at is pretty old and might need some love, I'm not surprised if there are bugs or weird behavior. There is a bit of complexity related to what decks that are used that will enabled/disable the assistance modes.
I think the intended behavior should be:

• "Altitude hold" - always enabled. Without any decks the barometer will be used, but if there is a deck that adds more positioning information that will be used. I think the functionality is that when you press the button, the Crazyflie will try to maintain that altitude. I guess it uses a setpoint with Z-velocity = 0 (no data for X/Y), but I'm not sure.
• "height hold" was added when we made the Z-ranger deck. I think it will use a setpoint with an absolute Z-position (again no X/Y). It should be enabled when there is a Z-ranger deck or any other positioning decks.
• "hover" was added mainly for the flow deck. It uses a mixed set point with velocity for X/Y and absolute position for Z. It should be enabled if the Flow deck or any other positioning deck is mounted.
• "Position hold" uses setpoints with velocity = 0 for X, Y and Z. Should be enabled for decks that supports absolute positioning (I think)

It is very likely that the trim functionality is broken, I'm not sure we have tested it in a long time (years) :-(
I'm not even sure what the intended functionality is.

[burakyueksel]

Thank you @krichardsson for the descriptions!

In "Altitude hold" mode I expected more control in altitude since baro and imu measurements are available. It first gave me the feeling that altitude hold is not working either. Then I went to the crazyflie firmware and I saw this:

https://github.com/bitcraze/crazyflie-firmware/blob/master/src/modules/src/position_estimator_altitude.c

It is a basic first order filter to the barometer measurements.

@krichardsson does that mean there is no sensor fusion (e.g. linear kalman filter) with acceleration from IMU + barometric height and some outlier detection and zero motion correction for estimating vertical state (acc bias, vertical speed, vertical height) using the onboard baro and IMU (although I see several kalman filter applications in the firmware repo, but they are not used for IMU+baro fusion I think)? Because that explains the behavior and altitude hold might actually be working as programmed, just not very good. Or I am missing stuff :)

To this specific topic, I can look into. The performance can be increased dramatically.

Coming back to the generic question of this discussion:

• I was thinking of creating new buttons in the interface dialog, and add the button_detect functions for them, which then does the job.

• But now instead I am thinking of recycling the code snaps used for trim, and see where that goes to.

Will update here when I have something. First I need to find some time.

[krichardsson]

does that mean there is no sensor fusion (e.g. linear kalman filter) with acceleration from IMU + barometric height and some outlier detection and zero motion correction for estimating vertical state (acc bias, vertical speed, vertical height) using the onboard baro and IMU (although I see several kalman filter applications in the firmware repo, but they are not used for IMU+baro fusion I think)? Because that explains the behavior and altitude hold might actually be working as programmed, just not very good.

There are two different estimators available: the complimentary estimator and the kalman estimator. A Crazyflie without any decks will use the complimentary one, while if you add a positioning deck, it will automatically switch to the kalman one. It is also possible to set the estimator manually through the stabilizer.estimator parameter

The code you looked at is probably used with the complimentary estimator (both the estimator and the baro code is very old), and there is no proper sensor fusion here. I think there is a barometer implementation in the kalman estimator as well, but I'm not sure how well it works.

The barometer has not got the love it deserves, and there is room for improvements in both estimators :-)