This topic might seem like a bad idea.
Here is my idea:
It is possible today to control a uav with Joystick via mavcontrol messages, this approach introduces lag and I’m guessing that part of it is because of overhead data.
I’m confident it cant be because of bandwidth.
If I’m wrong, please call me out on it.
And the joystick functionality is limited to the implementation within the GCS. (As APM2, it seem broken)
What I want to do is to directly through software act as an “radio” receiver I mean as far the system is concerned in the end is a list of min/max values, and I’m not sure how to approach this as I’m new to ardupilot, navio and mavlink.
What I’m trying at the moment is to take an crash course into what role every individual part has in the Navio2/RPi “ecosystem”.
This part is solved (open for ideas)
It would save me some time, if any one could point me in an “broad” direction.
For example, is the “hardware” exposing any memory that I can write to from userspace? Just started examining the rcio-dkms code (That might be totally wrong place to look - what it looked like it was very wrong)
Went on to investigate the ardupilot code inside copter-3.5 Navio branch.
Found some code of interest inside AP_HAL_Linux/RCInput_Navio2.h
and RCInput_UDP.h seems there is code that might come into use.
Just found this source of information http://ardupilot.org/dev/docs/learning-ardupilot-rc-input-output.html
It isn’t easy to navigate through all this information when all technical terms are so foreign to me. But it really helped to read the code.
Okey I have now spent an unhealthy amount of time reading code and I must say I love open source.
I stumbled over RCInput_UDP while reading/tracking the rcinDriver code inside HAL_Linux_Class.cpp
So my focus from writing my own Sender/Receiver software for RCInput to Navio2 has shifted towards porting the RCInput_UDP code to run with RCInput_Navio2 code.
The protocol used in RCInput_UDP seems slimmed and straightforward and best of all, I don’t need to meddle with it, the “Transmitter” is already implemented and opensource.
(As it seems I didn’t expect the time for “research” being longer then implementation)
Final update 2017-12-23
So the latest findings. Everything seems to work with direct joystick support.
Whats so different with my way of doing it.
Well in short and simple, instead of Radio communication as the physical layer to transmit “control”-signals via input pin 0, I use ethernet/UDP (basicly whatever method you can think of that supports TCP/IP, 3g/4g dongle, wifi and so on.).
What I know and heard, is that GCS has some sort of joystick functionality and the experience I have from APM Planner 2 is that it is flawed and laggy.
So possible Pros:
Joystick will function regardless of GCS.
to be added
How I did it.
Well simply reused the ardupilot code added for RCInput_UDP instead of RCInput_Navio2. Want to change this be a configuration option just as adding and changing TELEM options
On the Control station with connected joystick I use https://github.com/jberaud/joystick_remote
Got all the basic inputs working for Nvidia Shield Joystick with PS3 mapping. When time exist will probably add a pull request with all of the Nvidia mappings to the repo
If there is interest, I can make a detailed forum post with pictures and steps on how to make it work.