-
-
Notifications
You must be signed in to change notification settings - Fork 363
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add support for SpaceMouse mod (6D input knob) #1853
Conversation
7d278ee
to
37f30e5
Compare
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 😆 |
The more widely known 3Dconnexion products are USB based input devices for computers: https://3dconnexion.com/us/spacemouse/ |
Just ordered for Fusion360 maybe will try tour crazy idea 😀 |
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. |
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 :) |
@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. |
ATM I think our goals need to be set a bit lower 😅 Emphasis should be set on:
On low-level code (near to the HW):
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 ;-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a general comment: I would be super cool if we could use both AUX1/2 as source for spacemouse.
I tested the PR with physical SpaceMouse and TX16s on AUX1/2 -> works perfect. |
76d1d3a
to
7813660
Compare
@elecpower May I ask you to augment Companion with a serial port menu option |
@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. |
My plan is to have SPACEMOUSE generally enabled as an option for
|
@@ -7,6 +7,7 @@ option(AFHDS3 "AFHDS3 TX Module" ON) | |||
option(MULTIMODULE "DIY Multiprotocol TX Module (https://github.com/pascallanger/DIY-Multiprotocol-TX-Module)" ON) | |||
option(GHOST "Ghost TX Module" ON) | |||
option(HARDWARE_EXTERNAL_ACCESS_MOD "Support for R9M 2019 hardware mod" OFF) | |||
option(SPACEMOUSE "Support for SpaceMouse" ON) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this not be OFF by default to save cluttering the UI for the majority?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can work with the serial port setting being used to determine whether the 6 sources are visible to save adding the build option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
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. |
Thank you @elecpower 😍 results in: serialPort:
AUX1:
mode: SPACEMOUSE
power: 1
AUX2:
mode: GPS
power: 1
VCP:
mode: CLI
power: 0 and sources list smA to smF: 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: "" |
@rotorman I have a small yaml fix for A - F on its way when I can get github to see it |
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. |
89b303b
to
8a76d7c
Compare
Tested latest state (after rebase and now with LVGL updates - thx to @raphaelcoeffic ) on RM TX16S with one SpaceMouse module, fw built with @pfeerick may I ask you to double check this PR that it is not breaking any functionality for non-SpaceMouse users. Thank you! |
Sorry, missed the notification for this, I'll get back to you on that tomorrow. 🤞 |
Looks like you have some problems with source names being offset... This is also visible in Companion simulator, so you should see this in 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. |
Thank you for checking and finding this! |
Please note that defined(PCBHORUS) is used in MixSources enum.
dd125d6
to
a783a9d
Compare
Thank you for the TR_VSRCRAW /STR_VSRCRAW fix @raphaelcoeffic ! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ;)
Thx @pfeerick! Tested on real hw with SpaceMouse, all 6 axes of the knob still work as expected ;) |
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:
The values are made available as sources
smA
tosmF
(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