I am trying to use a Jetson nano attached to TELEM 2 of pixhawk, where I can receive sensor feedback, calculate control inputs and send all from Jetson nano.
My question is, can I use RC_override to control the motors even when I’m not in manual mode? My reasoning is because I don’t want to write path planning software to follow a path, depth hold, etc. I want ardupilot to calculate that stuff, then use the desired and actual states to produce an error state and calculate my own control inputs
I tried to put the ROV in depth mode while sending RC_OVERRIDE messages with 1500 pwm signal to see if I could override the autopilot thruster commands, but that did not work.
Any ideas on how I can keep the navigation portion working for me while overriding the control outputs?
All ArduSub’s external motion axis input commands are done via RC_OVERRIDES (MANUAL_CONTROL’s axes commands just get converted to RC_OVERRIDES internally), so they definitely work outside of manual mode. As an example, in depth hold mode the depth and yaw axes are used as manual overrides that control the vehicle, and once released (set back to 1500) the vehicle uses the current state as its new depth and yaw targets.
1500 is the “neutral”/“stop” signal, which is sent by default by a ground control station connected to a joystick, so is effectively treated as “no direct pilot input”. If you’re using code and want to explicitly command a stop I suppose you could command 1501 or something since that should still be within the ESCs dead zone but should be treated by the autopilot as intentional input.
I don’t know what happens when sending motion controls to a vehicle that’s trying to do position control, so it’s possible overrides will work as desired, but it’s also possible they’ll be ignored. I recommend trying with some non-1500 values, and if that doesn’t do anything we can try to find the relevant part of the source code to see what’s expected to happen
Thanks for the suggestion on using non-1500 values. That makes sense.
I just tried again to run my script publishing pwm of 1505 as RC_Override from a C++ script at ~100 Hz. I can view the RC_CHANNELS message in QGroundControl and chan1_raw - chan6_raw read 1505 as desired. Then I changed the mode from manual to auto and the thrusters instantly kick on at high speed.
So something is not working as desired with sending RC_Override in non-manual mode. I think my next step is to start looking through source code as you suggested. If you could point me towards the relevant files, that may help quicken the search.
I also need to look for a way to disconnect the motors from power so that the motors don’t go crazy when trying different methods to get this working. I can unplug the main battery after 1 second or so, but the noise is pretty horrible
If the vehicle is not in the water while you’re in an automated control/stabilisation mode then it’s very hard to predict what the servo values will be, and not surprising if they’re a bit whacky. In particular the pitch and roll specify a desired angle, so if they are not being met then the respective motors will push harder, and rapidly end up as strongly as possible (hence servos 5 and 6 here, trying to control roll).
Instead of trying to set a non-zero value for every motion axis at the same time, maybe try one at a time, and preferably while the vehicle is in the water?
Makes sense why 5-6 we’re trying to create roll motion as my pixhawk is out of the pressure housing and not in the correct orientation
Should it matter how hard the vehicle is trying to push the motors? My understanding was that RC_override would allow me to command my own pwm signals on those pins and that however hard the vehicle is trying would not matter
The RC_OVERRIDES correspond to motion axis commands (defined by the RC Inputs), not the motor PWMs. The interpretation of what the vehicle does given a particular motion axis input is dependent on the flight mode (e.g. in manual mode it goes directly to the motor outputs via the vehicle frame’s thrust factors, whereas in stabilise and depth hold modes some of the commands correspond to angle or rate targets rather than thrust outputs).
Oh wow. Okay. So it’s not really possible to be in a depth hold, stabilize, or tracking mode and have the desired states still publishing while having the ability to use RC_override like in manual mode where the channels are just fed directly through the thruster factor matrix?
That would be ideal so that we can introduce our own controls while still letting the vehicle use its depth hold/stabilize/etc. behaviors
While just testing in water is best, for bench testing you can either adjust the thruster limits or unplug the ESC signal wires and just look at / print the SERVO_OUTPUT_RAW values.
Correct, each flight mode has its own input handling, and there’s no built in overriding behaviour for the outputs that bypasses the flight mode’s intended actions, so if you want a flight mode that stabilises normally but treats inputs as manual overrides then you’ll need to write that as custom.
The RC_OVERRIDES terminology refers to overriding the inputs, namely from actual radio control channels, transferred in via the “RC” input (expected to be from a radio receiver, which is how other vehicle types are often controlled).
