@kikislater I agree… I ended up doing more changes and didn’t update the docs. What I think I need to do (or someone else) is to factory reset Disco, and then document all the changes needed. It would be good to have a install script in ardupilot as well to do that automatically. The script in dema-rc can serve as reference.
@mainframe yes, that is right. I merged this commit in arduplane stable, so it should be in arduplane 4.0.7 when @tridge releases it
Thanks Lucas, I built it and now I have RC from SC2.
Build is available here :
https://drive.google.com/drive/folders/1SQ8AA4iU0YomPnHrWplvY1WUGj1BSuY4?usp=sharing
To start fbwa at 0 throttle (due to stick at center) :
SERVO3_MIN : 1500
SERVO3_TRIM : 1500
RC3_MIN : 1500
RC3_TRIM : 1500
Roll and Pitch need to be reversed.
RC1_REVERSED : 1
RC2_REVERSED : 1
I need to check how to get video and it should be good !
On my pc (archlinux) there is one order to start QGC or MP before it works. Start Disco and SC2, switch respectively to arduplane (3 press on disco) and dema-rc (one press on param button), wait for solid blue in SC2 then connect cable to pc. Otherwise it will not work …
ok, but that means you will have just half the control in the stick. In the default parameters there is one to let you arm with the stick at the center, then just change to takeoff mode.
This is done automatically by QGC when you run RC calibration, but I guess it doesn’t hurt to add it to defaults
Disturbing in fbwa and I prefer this behavior furthermore for landing.
I have others frame with reverse trust and that’s what it’s missing in Disco with ardupilot due to i2c esc but never mind : landing pattern in QGC is ok.
I did it today, really simple to do
Phone or Laptop wifi <—> raspberry pi wifi <—> raspberry pi ethernet <—> ethernet adapter on Parrot Skycontroller 2 <—> Skycontroller 2 Wifi <—> Disco Wifi
Why do you have 14551 port here ? Not consistent again with your documentation …
nothing special. This is going to the USB and often enough I want to be connected to the USB but wtuhout the GCS autoconnecting since I’m testing the SK2 as the mavlink bridge. You could as well just disable autoconnection on the GCS side
Hi, sorry to bump the thread but I’m getting into this myself.
I’m currently running arduplane 4.3.7, a static build from the website.
Do I understand correctly that I will not be able to route video and MAVlink telemetry through the SC2 (i.e. Disco ←(WiFi)→ SC2 ←(USBEth)→ QGCS) unless I have the the libiio and libserial dynamically linked (which is impossible with a static build).
That is: Arduplane needs to be told to do something differently than stock Arduplane for this to work?
Or is dema-rc doing all the heavy lifting, and is (iptables) routing traffic from (drone) 192.168.42.1 to (laptop) 192.168.153.X, and that the laptop just needs to be configured to listen to the 192.168.153.1?
The routing should work as far as mavlink is concerned. For video, I don’t remember from top of my head if the rtsp was being routed too.
The routing should just work as far as mavlink is concerned.
What’s the setting I should be using in QGroundControl. I currently have it so:
My ardupilot commandline is:
arduplane \
-A udp:192.168.42.255:14550:bcast \
-B /dev/ttyPA1 \
-C udp:192.168.43.255:14550:bcast
but I notice that your commandline in the doc is:
/data/ftp/internal_000/ardupilot/arduplane \
-A udpin:0.0.0.0:14550 \
-B /dev/ttyPA1 \
-C udp:192.168.43.255:14550:bcast
whats the significance of the udpin vs udp
If I login to the SkyController, and run iptables -L inside my dema-rc SkyController, I see that no rules have been defined.
Is that expected?