DIY-Multiprotocol-TX-Module
DIY-Multiprotocol-TX-Module copied to clipboard
pascallanger
Updated CFlie protocol
This PR improves the CFlie protocol:
1) Switching to crtp_cppm_emu packets instead of crtp_rpyt packets
- aux channels can now also be transmitted, e.g. switching between attitude and rate mode is now possible
- scaling to attitude/rate setpoints is now managed on the drone (with crtp_rpyt packets, the attitude setpoint scaling is hardcoded in the multimodule firmware)
- crtp_rpyt packets can still be used via a define if desired
2) Enabling to set a fixed data rate and rf channel in OpenTX/Edge TX menu for flying with multiple Crazyflies and Transmitters simultaneously
- data rate is set via subprotocols, rf channel via option field
- "auto" subprotocol still allows automatic detection of the data rate and the rf channel
Tested with the following Crazyflie drones and flight controllers using JumperRC T-Lite 4-in-1 and Jumper RC T-Pro 4-in-1:
- Crazyflie 2.1
- Crazyflie Bolt 1.0
- Crazyflie Bolt 1.1
Disabled protocols such that CFlie fits in the memory (to be discussed):
- CABELL
- CG023
- DM002
From what I can see in the release build log, there should be enough space (highest is 98%) to not disable any protocols for this PR. Can you reenable the protocols to check the space?
You were right, just above the limit from a few hundred bytes... I've never looked at the Cflie protocol since someone else did the port as you did here with your improvements. I'm wondering if we could somehow reduce its footprint.
There might be some unused code for telemetry handling (the telemetry is not working at this point), but not sure how much we can save there. But I am planning to try to get the telemetry working and create another PR for that, once I find more time to work on it, so would prefer to keep it there for now.
Maybe there is another protocol that is not used much which could be disabled?
The CI now builds with one _Config.h an idea would be to add e.g. _ConfigObscure.h with less used protocols and another CI run to see to build with those. I indeed would rather see Updated CFlie protocol at the cost of a default less use protocol. Note that the disabled by default protocol would still be available for users, they just need to make their own _MyConfig.h, compile and flash that to their 4in1. There are likely better solutions but for now, comment out a less used protocol in the _Config.h IMHO. I would vote for FrSkyV >;-)
There are a lot of maple libraries links in that are not use e.g. IPAdress.* and i2c* ino core.a a quick removal of these we went from region rom overflowed by **700** bytes to region rom overflowed by **100** bytes to region... so a bit more toying around and we will get there. There are also still Maple libs debug stuff define that are not useful for 4in1 and be changed with DEBUG_LEVEL to 0. As soon As I have something that compiles and fits in ROM while still including per default all of the Protocols, I'll post a PR to shoot on :) There is more low level fruit to be picked like -flto or maybe even -fshort-enums (no guts no glory ;-) options. If added, ROM need very strict validation if all still works as it should... WIP
Is this protocol really still being in use? The current build does work, just not all the options are available...
Is this protocol really still being in use? The current build does work, just not all the options are available...
Yes indeed, and a lot and a lot more soon likely, see https://www.bitcraze.io/products/crazyflie-bolt-1-1/ Lots research facilities are using crazyflies, would be handy to have full 4in1 support. (Telemetry?)
I just came across this issue and since I know the https://flapper-drones.com/wp/ and was just busy updating and adding _My_Config.h to all of my 4in1 modules and in process of re-flasing and testing dozen or so TX's from OpenTX to EDGE TX internal modules to 1.3.3.20 a good chance to see where we could minimize the ROM size, since it seems a big thing if more space would be available. BTW I do have a Crazyflie to test even.
Even if the outcome would be a good way to "create" more space for the 4in1, that would not be to bad don't you think? ;)
Thanks for asking.
As @OpenUAS says, we are using it on the Flapper drones (powered by the Crazyflie Bolt board), that we produce. There are many more Crazyflies out there, people just weren't aware this has been an option... Now with many very affordable transmitters with 4in1 modules, people started noticing...
@OpenUAS I was not aware that it was still in use. And yes for sure I'll take any space saving. @matejkarasek I'm impressed by your flapping drones :D Is there a way to get a kit? That would allow me to look deeply at the code, simplify where possible and test my changes. I've never really looked into it due to the missing hardware.
@pascallanger Thanks for the compliments :) @OpenUAS has access to both a Crazyflie and one of our Flappers for testing. Would that do for now? We might be able to send you a testing platform later, can you send me an email to [email protected]?
Found some time today... Sketch uses 120400 bytes (99%) of program storage space. Maximum is 120808 bytes via compiler.cpp.extra_flags=-fshort-enums -fshort-wchar -flto , no rejoicing yet, still needs testing specifically -fshort-enums effect. An with IPAddress and I2c removed from maple core.a thus smaller. There is no doubt more possible, however the maple libs and build config are quit extensive to check and improve.
Found some time today... Sketch uses 120400 bytes (99%) of program storage space. Maximum is 120808 bytes via compiler.cpp.extra_flags=-fshort-enums -fshort-wchar -flto , no rejoicing yet, still needs testing specifically -fshort-enums effect. An with IPAddress and I2c removed from maple core.a thus smaller. There is no doubt more possible, however the maple libs and build config are quit extensive to check and improve.
@OpenUAS have you got any more updates on this? Happy to take a look at integrating/implementing whatever you have so far.
