New protocol for iNav flight control software

More
07 Sep 2016 20:59 #53603 by mjbudden
Replied by mjbudden on topic New protocol for iNav flight control software
1. I'll fix the Beken registers - that was just a bit of cargo cult programming on my part.

2. As for the 6 channel protocol, I'll get rid of it. At the back of my mind I had the idea that the smaller payload could be used on race quads - a smaller payload means faster reading and interrupt processing on the receiver. I was thinking of then having very low packet periods (say 1000us) so that the receiver would be updated at a high frequency. Then you could get rid of RC smoothing on the flight controller. But it's all a bit pie in the sky at the moment, and I haven't done any calculations as to its feasibility. So I'll leave it out for now and perhaps revisit the idea later.

Please Log in or Create an account to join the conversation.

More
07 Sep 2016 21:41 #53608 by Fernandez
Replied by Fernandez on topic New protocol for iNav flight control software
Hey guys this is interesting stuff, f.i. the revo F4 flight controller now has a UHF module connected via SPI, should we than just hook up the NRF module instead? Would it be faster latency wise? Could we send first 4 channels faster?

Would there be some future possibilities for having this direct open telemetry link between TX and Flight controller, to be able to enter a flight control settings menu for changing some basic stuff from your Tx, such as change pids, set failsaves, change the rates and spr expo etc etc.

Please Log in or Create an account to join the conversation.

More
08 Sep 2016 07:08 #53622 by mjbudden
Replied by mjbudden on topic New protocol for iNav flight control software
@Fernandez, I hadn't considered the possibility of replacing the REVO UHF module with a NRF, but that sounds an interesting possibility. One of the problems of attaching an NRF24 to a flight controller is that the SPI pins are often not easily accessible. Replacing the REVO UHF module is not too hard a soldering job. Same applies to the Sparky2.

As for latency, hardware wise I'm not sure. But software wise, I think we could get good latency. I haven't yet implemented interrupt processing in the iNav code - the NRF receiver is currently polled, but changing this should be fairly straightforward.

I've also been thinking of experimenting with much higher transmitter rates, eg 1KHz. Transmitter protocols seem to currently update at 200Hz or 250Hz (but I haven't really spent much time looking into this yet).

I'd certainly be interested in extending the telemetry to include more information, including PIDs and rates etc. Currently betaflight et al has facilities for changing these using the transmitter, so it would be just a question of extending the telemetry to be able to display them on the transmitter.

I'm very keen for people to experiment with this, and I'm very happy to make changes based on feedback from testing and suggestions for improvements.

Please Log in or Create an account to join the conversation.

More
08 Sep 2016 15:43 - 08 Sep 2016 15:44 #53638 by anthony7288
Replied by anthony7288 on topic New protocol for iNav flight control software
mjbudden

we wait this project come in soon , Nrf24l01 very cheap .
I try connect nrf24l01 to hardware Naze F1 ,, choose Nrf24l01 and protocol syma. But seem it not yet work ,
In Tab RECEIVER , i do not any signal display
Last edit: 08 Sep 2016 15:44 by anthony7288.

Please Log in or Create an account to join the conversation.

More
08 Sep 2016 18:20 #53645 by mjbudden
Replied by mjbudden on topic New protocol for iNav flight control software
@goebish

Your NRF24L01_Activate(0x73) tip fixed the problem.

It's funny, I knew about the ACTIVATE command, but the NRF24L01P documentation said it was not required, it's only required for the NRF24L01 (no P). I guess the cheap clones are non-P variants.

Please Log in or Create an account to join the conversation.

More
08 Sep 2016 18:21 #53646 by goebish
Replied by goebish on topic New protocol for iNav flight control software
Cool :)
I think you're right, but in doubt just use it.

Please Log in or Create an account to join the conversation.

More
08 Sep 2016 19:55 - 08 Sep 2016 19:59 #53647 by Fernandez
Replied by Fernandez on topic New protocol for iNav flight control software
@mj budden this flight controller:
www.banggood.com/OpenPilot-Mini-CC3D-Rev...er-5g-p-1018903.html

Is basically an REVOF4, it has same wiring to the F4 runs same firmware, but it has no UHF RF module, but the spi pins are wired to a connector, so you can hook up over SPI direct an RF module.
If you really go down that way and close couple RX into Flight control, than basically 4 fast control channels are needed all other setting switches etc, can be just a digital one bit no need for full channel save a lot of bandwith !
If you are going forward with this F4 and Betaflight, I'll definitively will follow this with great interest, I could test possibly as own this controller. If you spend all that time programming make sure you select the RF chip with best capabilities, possibly cc2500 used by Frsky, Futaba, Multiplex etc might be best choice?

For configuration from TX basically the CLI commands must be transferred from TX to Flight control, sound really great!
Last edit: 08 Sep 2016 19:59 by Fernandez.

Please Log in or Create an account to join the conversation.

More
09 Sep 2016 05:56 #53669 by mjbudden
Replied by mjbudden on topic New protocol for iNav flight control software
I didn't realise that the Revo mini brought all the SPI pins out onto a connector. I'll certainly get hold of one and get the code working on it.

Certainly one of the motivations for my work is to be able to increase the RX refresh rate.

In betaflight the current RX refresh rate means that the RX input can be "bumpy", so people often seem to use RX smoothing. A faster RX refresh rate might make this unnecessary. I think it might be interesting in experimenting with RX rates of, say 1KHz. (RX rates currently seem to be 200Hz or 250Hz).

It's already possible to use the TX to change the PIDs using the in-flight adjustments feature. This is available on Cleanflight/betaflight/iNav. See this post for how to do it: www.propwashed.com/in-flight-adjustments/

What is missing is the ability to display the PIDs on the transmitter - I intend to update the telemetry to do that.

Please Log in or Create an account to join the conversation.

More
09 Sep 2016 07:36 #53671 by Fernandez
Replied by Fernandez on topic New protocol for iNav flight control software
Yes but I believe it is not user friendly. all is just brainstorming here.......

For racing we need 4 high speed low latency control channels, then all switches possibly some variables etc do not need to take full channel of bandwith, just some bits and may have some latency too.? For pids and settings, it would even be fine if this can only be adjusted when quad is disarmed, so controls are off and system could go into kind of telemetry mode, basically the CLI commands can be send from Tx, ?

If a new menu's in deviation could be added in the future for configuring external devices as flight controller, esc setup, the whole benefit of this that you do not any longer need setup assign any channels etc,to setup pid etc and control wise it would create best link highest speed lowest latency.

Please Log in or Create an account to join the conversation.

More
09 Sep 2016 19:38 #53698 by mjbudden
Replied by mjbudden on topic New protocol for iNav flight control software
@goebish,

now that I've got the telemetry going, I'd like to add the PID values to the telemetry, so they can be displayed on the transmitter to facilitate tuning. However the telemetry pages don't seem to have an appropriate slot to display this data. Is it possible to extend these pages to show more values?

Please Log in or Create an account to join the conversation.

More
09 Sep 2016 19:49 #53699 by goebish
Replied by goebish on topic New protocol for iNav flight control software
You'll have to create a new telemetry type (there are already 3, frsky, devo and spektrum), have a look at the existing telemetry source code.
I've to do it for Hubsan and AFHDS-2A already, but I've been extremely lazy lately ;)

Please Log in or Create an account to join the conversation.

More
09 Sep 2016 19:51 #53700 by victzh
Unfortunately, Deviation does not have so convenient abstraction for telemetry as it has for control - Channels and mixer.

So telemetry is a bit ad hoc, not you're lazy, goebish.

Please Log in or Create an account to join the conversation.

More
09 Sep 2016 19:58 #53701 by mjbudden
Replied by mjbudden on topic New protocol for iNav flight control software
Currently I am using the DSM telemetry type and abusing some of the fields.

Creating a new type should not be too difficult, but I am concerned about ROM size. Won't doing this use quite a bit of ROM?

Please Log in or Create an account to join the conversation.

More
19 Sep 2016 15:38 #54033 by wasp09
Pick up this new protocol on git pull today. Where can we get iNav? Is that a flight controller like Naze 32 with RF builtin?

The protocol uses auto ack, I wonder if 3 or 4 in 1 can handle that.

Please Log in or Create an account to join the conversation.

More
20 Sep 2016 15:45 #54069 by victzh
Newer 4-in-1 should. Have not tested yet - real life interferes.

Please Log in or Create an account to join the conversation.

More
20 Sep 2016 22:28 #54075 by mjbudden
Replied by mjbudden on topic New protocol for iNav flight control software
iNav is flight control software, see github.com/iNavFlight/inav/releases

I'm also working on getting the iNav protocol into betaflight, it should be in betaflight 3.1 when that comes out.

Please Log in or Create an account to join the conversation.

More
21 Sep 2016 13:53 - 21 Sep 2016 13:53 #54098 by wasp09
That's what I found on the web too. Then why do we have inav_nrf24l01.c? How is iNav tied to NRF24l01? Is the iNav shipped with a certain flight controller? Which one is that?

If I can load the iNav FW onto my Nase32 10 DOF, I probably use it with a lemon DSM2 sat. How would I be able to use the iNav protocol which is nRF24L01 based?
Last edit: 21 Sep 2016 13:53 by wasp09.

Please Log in or Create an account to join the conversation.

More
26 Sep 2016 18:35 #54297 by wasp09
Downloaded the source. Looks like it is NRF24L01 on CC3D only. Is that correct?

Please Log in or Create an account to join the conversation.

More
26 Sep 2016 19:40 #54299 by mjbudden
Replied by mjbudden on topic New protocol for iNav flight control software
iNav is a fork of Cleanflight targeted for "navigational" rather than racing use. So it supports waypointing, GPS based position hold etc. It runs on a variety of flight controllers and supports a variety of receivers. I've recently added the ability to support a NRF24L01 receiver. There are currently builds for the NAZE, CC3D and CJMCU flight controllers, but I intend to add more builds in future.

If you are using a lemon DSM receiver, then you won't be able to use the iNav protocol - since it is NRF24L01-based.

Please Log in or Create an account to join the conversation.

More
28 Sep 2016 18:23 #54377 by wasp09
Thanks for the clarification.

I have to get another nrf24l01 RF module to try it out. It is bidirectional, hence we need the one with PA too.

Please Log in or Create an account to join the conversation.

Time to create page: 0.108 seconds
Powered by Kunena Forum