Support for different boards and airframes

[Cyberslug]

Hi Paul, as you may have guessed what is driving my suggestions are the different choices I have made for radio, ESP32-S3 boards and recently aircraft type. My latest suggestions for change are the following. I have actually implemented the first three of these and can create a PR if this interests you.

1. Add the ability to define the pins used in a central place. When looking at the various arduino pin definition files for example XIAO ESP32-S3 and WAVESHARE ESP32-S3 I notice that notation such as D0, D1 etc map to different GPIO pins on the ESP32-S3. This means that selecting D0 on one board is a completely different pin on another board. The pins are defined for each modelType for servos and motors and in config for auxiliary things, this could lead to errors when adopting a new board type. I suggest placing all the pin definitions in a separate file that is included as part of the config class.
2. Add the ability to swap red and green for the inbuilt Neopixel. I am using a Waveshare ESP32-S3 zero board (or a clone thereof - not sure) and I notice that the onboard LED appears to use GRB instead of RGB for setting the colour. The fix is to optionally swap red and green in the call to rgbLedWrite. I have come across this before in other projects. I suggest adding a config option "SWAP_NEOPIXEL_RED_GREEN".
3. Add the ability to power on (and hence calibrate) in an attitude other than flying level. My test plane (as are almost all my planes) is a tail dragger. The current calibration assumes that the plane is powered on in its flying attitude. I suggest adding pitch and roll trim to the config to allow for planes to be powered standing on their undercarriages. The roll trim is just for completeness.
4. Add pass through for additional channels. This is just an idea but my test aircraft is a little foamy with retracts. While I haven't looked at doing this it might be nice to add the ability to allow additional channels to pass through and be used for things like the retracts. Indeed this might actually already be possible. I also know there is a danger in making things difficult to understand here but it would be nice.

Just thoughts and changes I am making for my personal use. Just let me know if I am getting annoying.

[plainFlight]

Not annoying... I just need to keep up 🙂.

1, Board config is a good idea, other flight controllers do this. It's only with the latest release have I used new S3 board and I know it had pin issues but was lazy.

2, I too have come across the RGB issue it may have been on the Waveshare Zero or Tiny, so a constexpr to select between the 2 types is sensible.

3, I am unclear what you mean about calibration. It's only the gyro that is calibrated at power on and that doesn't care what orientation that is in at calibration?

4, Again a good idea but would need to keep it simple for users to configure and may need some sort of static_assert to check there are no pin clashes.

5, As you are thinking ahead have I missed a CRSF update/fix that I need to review?? ...quite looking forward to this base class as I would like to use esp-now as a radio link for my micro models.

Cheers Paul.

[Cyberslug]

Ok I will put together a PR to address 1 & 2. Possibly 3 pending your response to the following paragraph.

My understanding is that the calibration determines the offsets, i.e. what is level. Then for models using modes like Self-Leveled this is used to define what level is. Hence for an aircraft like a tail-dragger that level will have a nose up attitude. Sorry if I have missed something here, unfortunately I still haven't managed to fly this software yet. I am going to attempt today.

I agree regarding adding static_asserts to prevent configuration errors. Actually I would also like to change the way that the model type is selected to something similar to the radio protocol selection that I used. That enforces one and only one selection. I just don't want to overwhelm you. This can be a longer term goal.

Re CRSF - sorry yes - it turns out that the last commit to the CRSF branch was all that was required. I just edited my final comment to say that I was done. I have tested that extensively (on the bench) with CRSF and it works fine.

Regarding keeping up, my contributions will stop in two week for a month or so. As it happens I am heading to the UK for a holiday :-)

[plainFlight]

For point 3... only the gyro calibrates to set zero. The Madgwick filter 'warms up'. It does not matter what orientation the plane is in at power on as it reads the gravity vectors and calculates. As it is so heavily filtered it needs to warm up from its powered on state. I do this during the gyro calibration period for convenience. Warm up is achieved by temporarily lowering the filter weight to get a true level reading quickly.... out of interest note that one of my models I power on upside down as battery hatch is on the bottom.

I quite like the config file with constexpr = true/false... I just feel for someone new to the code base they can scan down and set what they want. I confess it has got a bit crowded with new features but static asserts should capture most issues.

Add a constexpr true/false for the RGB/GBR neopixel to config, and have a go at the board config. I will dig out a crsf receiver and test and hopefully fly at the weekend.

[Cyberslug]

I have a branch ready to create a PR but it assumes that the changes in PR #15 are accepted. The file ModelTypes.hpp has a large number of changes associated with both this and #15 so I think that it is best if I wait for your testing and acceptance.

Thanks for the heads up on gyro calibration and Madgwick filter. I do not yet follow fully but see now that my thoughts were a bit off in that regards.

Unfortunately I didn't get to test fly today, I did not have the servo update rate set correctly :-(

[plainFlight]

Items 1 & 2 have been implemented and committed to main. I went with using structures for different board types. On board neopixel and rgb/grb selection is also set inside the board structures... there is no implementation for external neopixel presently in Config.hpp but this would be an easy update

Item 3... as stated above model orientation at power on does not matter. Note if model is moved (by hand) faster than the set 250 or 500 degs/s then that will screw true level for many seconds until the madgwick filter catches up.

Item 4 is unimplemented. I like the idea of this but would like to keep my ledservo class. Therefore we will be limited to a total of 8 outputs. If this is implemented it will need careful thought on how users can configure it.

On a side note I am trying to steer clear of 3rd party libraries unless they offer significant advantages like SoftWire... v2.0 purposely moved away from an mpu6050 library as I felt it was in constant flux.

Digest when you can, hope holiday is going well.

[Cyberslug]

Off topic but I will be back in your neck of the woods on 5th and 6th April if you are flying I wonder if you would like to catch up. No worries if not. You can pm me a better contact method or your field location on RCGroups. I am also cyberslug there.

[plainFlight]

Sounds good, Monday is forecast better weather but will pm you with details and we can go from there.

Edit... I appear to have no ability to send pm on rcgroups but can receive?? If you bounce a message to user Paul.A.Cook I can hopefully respond.