feat: Add support for SpaceMouse mod (6D input knob)

[rotorman]

This PR adds support for 3Dconnexion SpaceMouse serial module 3DX–700039 as an auxiliary input device. SpaceMouse is an interesting option to get up to 6 channel control from a single hand. The SpaceMouse serial module provides 6-axis data (3 lateral displacement axes plus 3 rotational twisting axes of the control knob) at up to 100 Hz with 700 digit resolution (+/- 350 digits) per axis. Use -DSPACEMOUSE=YES CMake option to activate on Horus color targets.

This could be especially interesting for models that use many channels (think e.g. models with camera gimbals, model excavators, boats, tanks, trucks, robots). On the other hand, it could be an option for R/C modellers, who have only one hand at their disposal.

Electrically, the SpaceMouse module can be connected to the radios serial port. In the example radio pictured above, the RadioMaster TX16S, the SpaceMouse is supported either on the AUX1 or AUX2 port.

Mechanically the SpaceMouse module can be attached externally, as well as internally on some radios. Some further info, how to install it into the gimbal socket of a RadioMaster TX16S, can be found at my RCGroups posts here, here and here.

SpaceMouse is added as an option to the SerialPort menu:

By default, the SpaceMouse is sampled internally with it's maximum pollable sampling rate of 100 Hz using FreeRTOS software timer.

Basic interaction, incl. taring, is available via CLI. Following commands are supported:

spacemouse poll
spacemouse tare
spacemouse startstreaming
spacemouse stopstreaming
spacemouse trace

The values are made available as sources smA to smF (for SpaceMouse channel A to channel F) that can be used throughout the EdgeTX input, mixer and LUA options.

A brief video demonstrating this PR: https://www.youtube.com/watch?v=LGe9YQZE_vg

[pfeerick]

Is it just that I haven't used it, or does the zoom vs tilt control motions see pretty pointless...? spin and pan-up/down are good... but I'm stuggling to see how you could zoom AND tilt without one interfering with the other quite badly 😆

[rotorman]

The more widely known 3Dconnexion products are USB based input devices for computers: https://3dconnexion.com/us/spacemouse/
After a brief learning period, using SpaceMouse to position a volumetric model in a 3D CAD software, or navigating viewpoint in Google Earth becomes second nature and works very well across all 6 axes. I'd guess, you just have to try it out 😄

[JimB40]

Just ordered for Fusion360 maybe will try tour crazy idea 😀

[wimalopaan]

Very cool stuff @rotorman !!!

For anyone how is interested I've made a different solution: it constists of a small PCB with its own µC, that can be connected to the AUX port. The PCB has 2 ports for 2 SpaceMice, 2 general purpose ports (one is used as a connection to the radio and/or an additional small receiver for a connection of 2 radios, and one may be used as additional input via Sbus e.g. incremental knobs) and one bluetooth connection to connect a smartphone or tablet.

[pfeerick]

The more widely known 3Dconnexion products are USB based input devices for computers: https://3dconnexion.com/us/spacemouse/ After a brief learning period, using SpaceMouse to position a volumetric model in a 3D CAD software, or navigating viewpoint in Google Earth becomes second nature and works very well across all 6 axes. I'd guess, you just have to try it out 😄

I think it was more the type of movement didn't seem quite so clear from the illustration... it seems to be more like the horizontal is more like that of the joystick pointer nub on a laptop than that of a gimbal (thus overall more like rolling a ball). I can see from this review how well it lets your control things in a 3D space, so for a model this should be an excellent input option for some people :)

[rotorman]

@wimalopaan could I kindly ask you please to review this PR (you have the SpaceMouse modules and the TX16S).

[wimalopaan]

@wimalopaan could I kindly ask you please to review this PR (you have the SpaceMouse modules and the TX16S).

Yes, I can test the function and look into the code (maybe I do not understand all parts of it).

Because I'm very new to this project I want to ask one general question before running into the wrong direction (not only related to this PR): as a personal point of view I would try to modernize the code for all new features and additions, and try use more helpful c++11 features (c++14/17 is not yet possible, AFAIK) and do things class-based (maybe OO), use strong and domain-specific data-types, reduce CPP usage, ...

Please don't get me wrong here: I try to understand the policy in this project with a faily large amount of legacy code. So, if you (the core project maintainers) say, the above mentioned points are (maybe) nice to have but not essential, and there is no goal in the foreseeing future to migrate in this way, it is absolute ok for me.

[raphaelcoeffic]

Because I'm very new to this project I want to ask one general question before running into the wrong direction (not only related to this PR): as a personal point of view I would try to modernize the code for all new features and additions, and try use more helpful c++11 features (c++14/17 is not yet possible, AFAIK) and do things class-based (maybe OO), use strong and domain-specific data-types, reduce CPP usage, ...

Please don't get me wrong here: I try to understand the policy in this project with a faily large amount of legacy code. So, if you (the core project maintainers) say, the above mentioned points are (maybe) nice to have but not essential, and there is no goal in the foreseeing future to migrate in this way, it is absolute ok for me.

ATM I think our goals need to be set a bit lower 😅

Emphasis should be set on:

• maintainability (factorise where possible)
• readability (avoid long lines, huge functions, use the clang-format defined)
• layer separation (see "maintainability")

On low-level code (near to the HW):

• 100% compliance with data sheets
• document choices if non-obvious

And this is already quite a task. In the course of years, the code has been "frankenstein-ised" quite a fair bit due to the different maintainers and huge legacy. Let's try not to add too much to that ;-)

[wimalopaan]

As a general comment: I would be super cool if we could use both AUX1/2 as source for spacemouse.

[wimalopaan]

I tested the PR with physical SpaceMouse and TX16s on AUX1/2 -> works perfect.

[rotorman]

@elecpower May I ask you to augment Companion with a serial port menu option SpaceMouse and the added mixer sources smA to smF? Thank you!

[elecpower]

@elecpower May I ask you to augment Companion with a serial port menu option SpaceMouse and the added mixer sources smA to smF? Thank you!

@rotorman can you confirm my interpretation of the change, in that the feature is implemented as a firmware compile time option for any target radio else hidden? Is so I will need to add another Build Option to the radio profile of all radios.

[rotorman]

My plan is to have SPACEMOUSE generally enabled as an option for horus class radios, w/o any explicit compile time option required (enabled by default, so that end-user only needs to pick it from Serial port menu):

edgetx/radio/src/targets/horus/CMakeLists.txt

Line 10 in 7813660

option(SPACEMOUSE "Support for SpaceMouse" ON)

[elecpower]

Should this not be OFF by default to save cluttering the UI for the majority?

[rotorman]

That is a question of how we want to proceed.
My idea was to list all options that we have (GPS, SPACEMOUSE, in the future MAVLink and so on), to avoid that the user has to have custom builds.
What would you suggest @raphaelcoeffic and @pfeerick ?

[elecpower]

I can work with the serial port setting being used to determine whether the 6 sources are visible to save adding the build option.

[pfeerick]

I have no issue generally with stuff being on by default - with the build option being there to remove that feature if tight on memory, debugging, or need to create a 'lite' or feature limited firmware build. In this instance, I think we need options on the hardware page that allow you to turn the mods on for the uncommon ones, thus enabling their visibility in the other pages. As the reality is we shouldn't have this mod on-by-default for the five people out of 5000 that might do the mod ;)

[rotorman]

I hear you. Thus, I will add a checkbox "Support mods" under SYSTEM -> Hardware, that is by default off. In such case, SPACEMOUSE should not be listed under serial port options, nor smA to smF listed in MIXSRC list.
Would be grateful for tips how to achieve the hiding best?

[elecpower]

Companion support added. The user needs to set either AUX1 or AUX2 to SpaceMouse for smA thru smF to appear in the list of sources.
This needs more testing!

[rotorman]

Thank you @elecpower 😍
Companion changes look nicely working!

results in:

serialPort:
  AUX1:
    mode: SPACEMOUSE
    power: 1
  AUX2:
    mode: GPS
    power: 1
  VCP:
    mode: CLI
    power: 0

and sources list smA to smF:

Setting them as:

results in YAML although to:

 - srcRaw: SPACEMOUSE_1
    scale: 0
    mode: 3
    chn: 4
    swtch: NONE
    flightModes: 000000000
    weight: 100
    offset: 0
    curve:
      type: 0
      value: 0
    carryTrim: 0
    name: ""
  - srcRaw: SPACEMOUSE_2
    scale: 0
    mode: 3
    chn: 5
    swtch: NONE
    flightModes: 000000000
    weight: 100
    offset: 0
    curve:
      type: 0
      value: 0
    carryTrim: 0
    name: ""

[elecpower]

@rotorman I have a small yaml fix for A - F on its way when I can get github to see it

[rotorman]

Aah, perfect, I just noticed this as well, that YAML lists 1 to 6 still, so I did not change it correctly before as it seems.

[rotorman]

Tested latest state (after rebase and now with LVGL updates - thx to @raphaelcoeffic ) on RM TX16S with one SpaceMouse module, fw built with -DSPACEMOUSE=YES. All 6 channels of SpaceMouse work as expected - here a short video showing this:
https://www.youtube.com/watch?v=zlKF2ZO4wgQ

@pfeerick may I ask you to double check this PR that it is not breaking any functionality for non-SpaceMouse users. Thank you!

[pfeerick]

Sorry, missed the notification for this, I'll get back to you on that tomorrow. 🤞

[pfeerick]

Looks like you have some problems with source names being offset... This is also visible in Companion simulator, so you should see this in simu which will help with fixing it. Seems to the only issue so far.

Did the mods option for Companion get put on the backburner? ;) It's not essential... once the source offset is fixed I think this should be right for merging.

[rotorman]

Thank you for checking and finding this!
Discussed with @raphaelcoeffic and the best option would be to change the functions using the combi-string TR_VSRCRAW /STR_VSRCRAW throughout the code to use directly only the parts they need. Presently the usage of STR_VSRCRAW is based on somewhat unintuitive indexing and can be error prone. Thus, getting rid of this, is a positive direction.
@raphaelcoeffic promised to look into this, so let's wait for his magic.

[rotorman]

Thank you for the TR_VSRCRAW /STR_VSRCRAW fix @raphaelcoeffic !
I just tested this on TX16S mkII with SpaceMouse and it looks good to me. @pfeerick may I ask you to re-check this PR when you find the time - thx!

[pfeerick]

Looks good to me. Can you check the commit I made doesn't break on your hardware - it's working for me on simu. Should remove the sources if you haven't actually enabled the SpaceMouse in the hardware tab ;)

[rotorman]

Thx @pfeerick! Tested on real hw with SpaceMouse, all 6 axes of the knob still work as expected ;)