Standalone CF control with any PPM compatible RC transmitter

[ali]

Hi,

I've written a little AVR program to control the Crazyflie without a PC or even the Crazyradio. All you need is a RC transmitter with trainer port or TX module slot that will put out a PPM signal, an AVR (almost any kind of AVR based Arduino will do, I developed this on an Arduino UNO), and a nRF24L01+ module (available at eBay for two bucks a pair) to talk to the CF.

The code is available here: https://github.com/alibenpeng/ppm2crazyflie

Flying is super smooth and responsive.

My work is based on these two projects:

http://thomaspfeifer.net/ppm2usb_adapter_en.htm
http://goo.gl/LNDuv9

I am planning on designing a little board to fit in JR/Graupner compatible module slots. I'll be back later with more info on that, if anyone is interested.

Enjoy!

[tobias]

Great work ali! This is something we have wanted to do for a long time but never got the chance to. Great to see that someone else did!

[ivandevel]

Wow! Great! How about alt hold mode?

[ali]

I guess it could be done by assigning switches on the remote to spare PPM channels and having the module firmware send custom commands like alt-hold or arm/disarm.

I'll look into it.

[ali]

Wow! Great! How about alt hold mode?

I think I've got it. Now PPM channels are assigned as follows:

1: Yaw (Rudder)
2: Pitch (Elevator)
3: Thrust (Throttle)
4: Roll (Aileron)
5: Arm/Disarm (simply realized by setting setpoint.thrust=0 if PPM input is < 50%)
6: Hover/AltHold (if PPM input > 50% flightmode.althold is set to 1 in the CF)
7: X-mode (if PPM input < 50%)
8: Protocol (not used yet, preparation for multiprotocol support as seen here: https://code.google.com/p/rc-ppm-2-spi/)

I also included (very basic) FrSky compatible telemetry support, so that the CF's battery voltage shows up as voltage 1 on OpenTX's telemetry screen. I'd like to include the CF's RSSI, but from what I read on the interwebs that seems to be a problem with the nRF24 chipset.

Also the PCB is making progress. I've committed a first version here: https://github.com/alibenpeng/9x_avr_tx_module
There are two electrically identical versions, one optimized for production in a fabhouse and the other one optimized for prototyping on a cnc router.

One thing that always bothered me about the CF is that it is (or at least looks and feels) very fragile, so that I am always over-cautious when flying it. since it's my first quadcopter and I'm not really good at flying it yet, I figured it would be a good Idea to get something that can take a bit of abuse to practise flying. So I went and bought me a Hubsan X4 which is getting top notch reviews, but also uses a different transceiver chip than the nRF24. So right now I have to decide if I'll design a second module for the A7105 (the transceiver ship the Hubsan uses), use the one from the link above, or extend my original design to include two transceivers, which might get a bit tight, both in terms of code and also space in the module case.

Since I'm totally torn between options 2 and 3 (not much sense designing another A7105 module if there's a nice one already out there) I'd like to put this up to discussion: Is there anyone besides me who would want a nRF24/A7105 combo module with multi-protocol support? Or is this really a thing the world doesn't need?

Any input on this is appreciated.

Cheers!

[ali]

Great work ali! This is something we have wanted to do for a long time but never got the chance to. Great to see that someone else did!

Funny thing I found this http://www.airspayce.com/mikem/arduino/ ... ample.html only hours after I got mine working.
And it's from 2012 apparently..

[ivandevel]

Hello! Can I see your alt hold mode setting code?

[ali]

Hello! Can I see your alt hold mode setting code?

Hehe.. first bragging about it and then forgetting to push the changes to github.
It's all there now.

Cheers.

[ivandevel]

Hello! I've tested your code. Hover parameter is setting correctly. But when I set it, crazyflie goes crazy (jumping). How to control crazyflie in hover mode? Which range are valid for setpoint.thrust ?

[ali]

Hello! I've tested your code. Hover parameter is setting correctly. But when I set it, crazyflie goes crazy (jumping). How to control crazyflie in hover mode? Which range are valid for setpoint.thrust ?

Maybe this behavior has something to do with the fact that on a RC remote the throttle stick does not center automatically while on a game controller it does.
This line in commanderGetAltHold() suggests this guess is correct:

Code: Select all

  *altHoldChange = altHoldMode ? ((float) targetVal[side].thrust - 32767.) / 32767. : 0.0; // Amount to change altitude hold target

So it looks like the CF is expecting exactly 50% thrust (or half an uint16, more accurately) in althold mode. Hence the jumping when the stick isn't exactly centered.
One thing to try could be to expect input on another PPM channel when in althold mode and map an unused pot on the TX to it.

In the CF setpoint.thrust is a 16 bit unsigned int, so I figure the valid range is 0-65535. The effective range is a different matter, though. That seems to be clamped to 60000 in the CF fw.
I altered my code to send the full int range when in althold mode and 0-60000 when not. I also added defines for the channels plus one extra for althold-change, which can be assigned to throttle or any other channel desired. And yes, this time around I remembered to push the change.

Let me know how it works out, as I won't be able to test it until after the weekend.

Cheers,

Ali