Betaflight-configurator: [Feature Request] Channel endpoint calibration (rxrange)

[ademuk]

An automatic way of calculating and setting rxrange.

One possible implementation:

• User is instructed to move sticks to extremes
• rxrange is automatically calculated
• Channel mapping could also be ascertained

Long term user of BF here, and I'd love to contribute back. Just putting a feeler out for whether this would be a desirable feature. I know I'd use it.

[ace-archer]

Just voicing my support for this as a hobby shop employee who configures quite a few quads with radios that don't have an endpoint adjustment option built in. Most notably the Spektrum DXe radio is a radio that a lot of beginners get due to low price point (~$60), but I've had a notable number of people come back to the store confused as to why their quad won't arm, or what they need to do to configure it. Because of that, having a feature to automatically set these values would be extremely valuable.

Also as a note, this would definitely seem like it requires coordination with betaflight-configurator

[ademuk]

@mikeller I had a little look at this a while back. My progress involved adding 2 new MSP codes, one for setting, and another for getting rxrange settings. Is this the right approach?

[mikeller]

@ademuk: Yes, adding this to the firmware would be a sensitive first step, before adding the actual code to the configurator. There is already code in the Modes tab that allows auto-detection of switch channels, this could probably serve as a template.

[ademuk]

After almost 12 months (!), I've found the time to tinker with this. I've put a little UI sketch together to demonstrate how it could work:

https://ademuk.github.io/tx-calibrate-poc/

NOTE: TX and MSP at the bottom half of the screen are just for the purpose of the demo, and of course wouldn't appear in actual BF Configurator.

What it does:

1. Inform the user to turn on tx/rx, reset tx trims etc.
2. In the case that rxrange is not set to default, instruct user it will be reset ahead of calibration.
3. Prompt user to move sticks to extremes one by one, this allows detection of channel mappings and channel ranges.
4. Propose new rxrange and channel mapping settings to users, before applying.

A few considerations:

• I'm not wedded to this particular way of calibrating. I know other UIs use the "circle your sticks all around" technique.
• I do however like the idea of visualising the channel ranges to the user, how your tx endpoints can be out of sync with the 1000/2000 range, and most importantly how rxrange can address that. Educating the user somewhat, instead of just doing the wizardry behind the scenes. (Lots to improve in regards to this)

I look forward to some feedback!

[mikeller]

@ademuk: I had a play with your mockup, a couple of points:

• it would be helpful if the detected range for each channel would be displayed for each detected channel;
• detection should require a certain threshold to be exceeded, so that if they bump a stick, or move in one axis while trying to detect the second axis on the same stick this is not accidentally detected;
• I think that if the user moves more than one axis while a detection is ongoing, the last axis moved should be assumed to be the desired one - they might first move the wrong one, then notice their mistake, and move the correct one;
• if, during a detection step, only an axis that has already been assigned is moved, an error message should show when they click next, telling them that this axis has already been assigned, and asking them if they want to redo the last axis, or start over.

[ademuk]

Hi @mikeller, thanks for taking a look.

I don’t think we’re far off any of those points.

On points 1 and 2. The detected channel appears on the left hand side. Did you not experience this, maybe you didn’t the meet the threshold? The threshold is 400us, so you’d have to go as far as 1100 or 1900. This threshold is of course configurable.

Point 3. This is also the current behaviour. The demo TX sliders do not currently spring back to centre, so this may result in weird behaviour if you drag several to their extremes. Otherwise this should work as you’ve described.

Point 4. Currently moving an already assigned channel will have no affect (the next button won’t enable itself, nor will it be marked as detected a second time). We can do that though, add an error message.

[mikeller]

@ademuk:

On points 1 and 2. The detected channel appears on the left hand side. Did you not experience this, maybe you didn’t the meet the threshold? The threshold is 400us, so you’d have to go as far as 1100 or 1900. This threshold is of course configurable.

I'd show the detected range as well as the detected channel - maybe the range to the right?

Point 3. This is also the current behaviour. The demo TX sliders do not currently spring back to centre, so this may result in weird behaviour if you drag several to their extremes. Otherwise this should work as you’ve described.

I would not rely on the sticks going back to center - this will not hold true at least for throttle. Instead I would detect a slider as moved if it has moved at least the threshold distance from when the stage was entered / last stick movement was detected.

Point 4. Currently moving an already assigned channel will have no affect (the next button won’t enable itself, nor will it be marked as detected a second time). We can do that though, add an error message.

I think adding an error message makes sense, otherwise an user will get frustrated because nothing is happening.

[ademuk]

Ah yes, I had the ranges show up at some point, it wasn’t d a little busy so removed them. I’ll add them back.

I’ll revisit moving multiple sticks one after the other, make sure it’s robust.

I’ll also have a look at an error message too.

Other than that, I need to wire it up with the Configurator codebase and add a set/get to the firmware for rxrange. I’ve built this prototype using React. Is there any interest in modernising the Configurator tech stack? This kind of UI with all its state is a perfect fit for React IMO.

[mikeller]

There definitely is interest in modernising - the current codebase based on jquery is horrid. Any help for this will be appreciated, but I suspect it will be a huge undertaking, and having to maintain compatibility with the chrome web app (which still seems to be used by many users) won't make it any easier.

[ademuk]

Great. From my experience, the best and only way really is to do it iteratively. You couldn’t possibly port everything at once.

• We add this feature using new tech (React in this case), in tandem with existing query codebase.
• Any new features would be built using these new these techniques.
• Everytime existing code is touched/changed. A refactor to new is mandated (a little more ambitious, but necessary)

I’d be very happy to help. I think there’s huge potential for a more automated Configurator. Auto rx detect, motor mapping etc. It’s important the dev experience is on point so people can easily contribute.

[mikeller]

@ademuk: It will definitely have to be iteratively - there were a number of past efforts to do a full rewrite of configurator, and all of them failed on the scope of the work.

I think react would be a good candidate for a replacement technology, as it is not a framework but just a library, and as such would lend itself to be just used for individual new features mounted inside the existing tabs - even rewriting configurator one tab at a time would be daunting - some tabs are huge, with just about zero structure.

[ademuk]

I couldn’t agree more with that. Let me tackle this calibrator, and then maybe I’ll have a go at refactoring a tab next.

[McGiverGim]

Great work, @ademuk.
If you refactor some of the tabs, maybe I can try to do it with others when I have some time (I never worked with react so is a way to learn a bit).
As you will see, the worst part of the Configurator is the code that makes it work with older versions of the firmware. There is a lot of conditionals adding complexity to support different versions.

[ademuk]

Sounds like a good plan @McGiverGim.

I think I’ve seen that, something around msp api version? Maybe we can build something nice to abstract some of that conditional logic.

[McGiverGim]

The MSP part is the cleanest part... The worse is in all the js that belong to each tab.

[mikeller]

The MSP part is the cleanest part... The worse is in all the js that belong to each tab.

Wholeheartedly agree. But I think with a move to React we could improve the situation considerably by feeding the firmware API version into the top of the virtual DOM, percolating it down, and having every component know what version its contents need, and then either render or hide the contents based on the actual version.

[ademuk]

Hey Betaflight fellows,

Good news!

I've finally gotten around integrating my (React based) PoC into the configurator, including read and write MSP communication. It works!

Check out my branch. It's not yet fit for a PR.
https://github.com/betaflight/betaflight-configurator/compare/master...ademuk:rx-calibration

And the required firmware change to support setting/retrieving rxrange via MSP.
https://github.com/betaflight/betaflight/compare/master...ademuk:rxrange-msp

I wanted to check in to see whether this was still a desired feature, and that the dev team still supported the introduction of React into the stack, at least before I pushed on to start testing/polishing my branch into something PR worthy. I hope it is!

Let me know your thoughts. Have a look over the code change. I've added a nice React hook API useMsp, which makes working with MSP comms sweet IMO!

[McGiverGim]

It's better to open the PR. It will have more visibility to be discussed. Simply state in the PR that it's open for discussion. In this way we can link the PR from slack too.

[ademuk]

@McGiverGim Makes sense. Here it is: https://github.com/betaflight/betaflight-configurator/pull/1769