Hi there,
is it possible to arm a PIxhawk without a ground station? I want to connect a RC receiver directly to a pixhawk.
Alternatively, is it possible to let the Pixhawk directly switch to arming when turning on?
Greetings Robert
Hi @Robby2001, welcome to the Blue Robotics forum 
Yes - you just need some way of getting a MAVLink message to it that tells it to arm, which could be from an onboard/companion computer
From our docs:
Assuming this is for a boat rather than a sub, you likely want ArduRover instead, in which case I’d recommend you check out the ArduBoat category of the general ArduPilot forum, as well as the ArduPilot docs
You could conceivably build a firmware that does that, but I wouldn’t recommend it.
Hmm, that´s a little bit disappointing.
i don´t want to carry an expensive and vulnerable Laptop with me, when i´m out on a “mission”. I prefer a light RC Transmitter and FPV googles.
So it´s quite a shame, that it´s the only way to control a ROV with build in Pixhawk to use a onboard computer and a Laptop as a ground station. And an onboard computer only for the purpose of arming the ROV, that is ridiculous.
So this is the last try:
What about this safety switch? Does this perhaps work?
Greetings
Robert
Are you aware that water is highly absorbent of radio waves? Standard RC transmitter communication may be possible, but it would need to be to some electronics on a surface vessel, that can relay the communication via a tether (or possibly an acoustic link) to the vehicle.
An acoustic link with sufficiently high bandwidth to stream video would need to be custom, and would be very expensive, so most ROVs use a tether. I’ve seen one truly wireless ROV which uses visible light for communication (water strongly absorbs pretty much the whole rest of the spectrum), but it has a range limit of 50m (which decreases with ambient light, water murkiness, and/or water turbidity), and the system is custom, experimental, and was only announced last year.
Assuming you’re using a tether of some sort, the communication is then already electronic, so there isn’t much sense in converting it back to radio waves inside the vehicle only to receive them right next to the transmitter and feed them into the flight controller, so it doesn’t make sense for ArduSub to need to support direct control via an RC receiver.
Instead, we use an onboard computer (Raspberry Pi) to make a serial connection with the flight controller, and relay messages between the flight controller and the topside. We also use the onboard computer to stream video (from a USB camera) up the tether, although a video stream is also possible with an IP camera and a network switch (so an onboard computer technically isn’t essential for that aspect).
I didn’t mention a laptop being a requirement, but we do tend to recommend having a topside computer as a ground station because (at least at this stage) it’s the easiest way to get consistently good results. Tablets are also a possibility, and phones may work as well, but they’re much less commonly used than computers, and less easy to set up.
I’m aware that it can be set up as an arming check, but I haven’t come across anyone actually using that for an ROV, for the reasons discussed in those docs. It’s worth noting that an arming check is not the same as actually arming - the switch isn’t intended to be used to arm the vehicle, but it can be set up so that the vehicle can’t be armed unless the switch is turned on.
As with the “arm as soon as turned on” behaviour you originally suggested, you could conceivably create a custom version of the firmware that uses the switch to actually do arming, but it’s not something I’d recommend (it’s work that would seemingly be for not much benefit, and forces someone to be very close to the vehicle when arming it).
Hi Eliot,
Sure. So may i present my system?
The RC signals are transmitted to the buoy. An sbus receiver inside the buoy sends the sbus signals through the tether. An sbus decoder inside the ROV generates the PWM signals for the ESCs. Quite simple. The AV video signal takes the opposite direction and is sent via transmitter inside the buoy to the FPV googles.
This equipment is light, quite inexpensive, reliable and KISS (keep it simple, stupid).
A laptop or a ground station would be a hindrance.
That would be the best possibility, but i´ve got no knowledge how to create or edit firmware. 
By the way: the rc signals can send to a pixhawk via sbus. Tha´s no problem.
Greetings
Robert
Cool! That’s not a setup I’ve come across previously, but it’s an interesting one
We have a guide for getting and compiling ArduSub, and the code is plain text - the potentially challenging part would be determining which files need to be changed, and how.
As I understand it ArduSub doesn’t support that. I’ve asked internally whether it would be difficult to enable - I’m not sure if it’s effectively “turned off” from the base ArduPilot functionality, or if it’s entirely “not implemented” (e.g. if all our control functionality would need to be rewritten to make it an option).
I’ve also asked how difficult it would be to set up using the hardware switch for arming (instead of just as a check), or if there’s some other way to arm without an onboard computer.
We’ve done some digging, and there’s somewhat mixed news.
It’s possible (although not confirmed) that RC commands via SBUS would at least be able to get through to the vehicle, but the mapping of input channels is very much hardcoded, and configuring them is unfortunately in the “not implemented” camp.
There are parameters that have been carried over from the base ArduPilot, including RCn_OPTION which would in principle allow specifying a channel you want to use for arming (which would solve the “how to arm without a GCS” issue), or changing to a particular flight mode, but the functionality itself is not available.
For reference, here is the RC channel implementation for ArduCopter, and here is the same file for ArduSub (it’s basically empty).
From an interface perspective, the “nicest” thing for supporting minimal control via an RC receiver would be to implement arm/disarm toggling on a currently unused input channel, and possibly mode toggling/cycling on another channel.
@williangalvani has graciously made a branch that copies across the parts that are most likely relevant for enabling arm/disarm control, but we haven’t yet tested whether that works as hoped.
If you’re willing to test, the steps would be:
- Build ArduSub with those changes (and your frame configuration, if your vehicle doesn’t use one of our default options)
- Set a (currently unused) channel to use the ArmDisarm function (e.g. by setting the
RC12_OPTIONparameter to 41) - Send a relevant, RC input to that channel (either via an RC receiver, or possibly mavproxy or similar)
- See if arming/disarming happens as commanded
On this front, it may be possible to add a process like this to the end of the initialisation function, which gets called as part of the vehicle setup. That’s also untested, so I’m not sure if it would work.
2 Likes
Hi Eliot,
first of all, many many thanks for your efforts 
That works, i´ve tested that! The RCin port of the Pixhawk is still “online” in ardusub. The channel mixing depending on the frame layout is also working. For me, the only hurdle is the arming.
You´ve sent me some links for reading and testing. I´ve never edited or written a firmware but i´ll try it. Perhaps i can get some help from these guys: https://u-rob.com/
They are using ardupilot software for their UAVs.
Also many thanks to Willian Galvani for the work
Greetings
Robert
Hi Eliot,
i´ve read your links how to get and compile ArduSub. For me it´s much too complicated and too wasteful. The only purpose for installing a pixhawk in my ROV was to use the depth hold function. I think, implementing this function by using a simple arduino would be easier in this case.
But many thanks for your tips and effords.
Greetings
Robert
Fair enough - hope that goes well!
Feel free to post any follow-ups, be that questions or progress
You’re most welcome