Trying to understand the difference between RC and Mavlink

Dear All,
I am new to ROSflight and some things are not totally clear to me. I do not really understand the distinction between RC and Mavlink in the code architecture on page http://docs.rosflight.org/en/latest/developer-guide/code-architecture/.
In particular, I thought that the "offboard" computer was on the same physical computer as the flight controler, so why need Mavlink?
Also, if you need Mavlink to send commands back and forth between the flight controler and the "offboard" controler, then what is RC?
Is RC only for joystick command (i.e. manual). So if I were to do something totally autonomous with my own algorithm and software, I would only use Mavlink and not RC?
Please if someone could bring a bit of light I would hugely appreciate :)

Comments

  • 5 Comments sorted by Votes Date Added
  • Hi @arta,

    An overview of how the RC and companion computers work together is given on this page; if there are improvements we can make to the documentation though we'd love suggestions or pull requests! Hopefully the following will help though:

    The "offboard" computer (this is maybe a confusing name and I think sometimes we call it the "onboard" computer too; "companion computer" might be a better term) is a distinct computer (like a Raspberry Pi, for example) from the flight controller, but is typically mounted on the vehicle and connected to the flight controller over USB. See this page for more info. The companion computer and flight controller communicate over USB using the MAVLink protocol.

    The RC connection is the connection from an RC transmitter to the flight controller, via an RC receiver. This is used for manual piloting of the aircraft, as well as for safety pilot functionality. The safety pilot functionality is summarized here.

    While it would technically be possible to do away with the RC connection for a totally autonomous solution, we have decided not to support this for safety reasons (related discussion here). Right now, you must have an active RC connection to arm the vehicle, and in fact RC is the only way to arm it. This is intended to enforce the presence of a safety pilot so that there is always a way to take control of the vehicle and disarm it in case something goes wrong (especially when dealing with research code!).

    So, currently for a "fully autonomous" solution, you would still need to arm and disarm the flight controller using RC. This seems like a reasonable tradeoff between flexibility and safety for a research platform, and anyone wanting to develop this into a completely autonomous solution is welcome to fork and make those modifications themselves. That's a riskier way of doing things though, especially during development, so we just don't want to enable potentially dangerous situations out of the box :)

  • This helps a lot! Thanks for the prompt answer!

  • Let me see if I got this right.
    1. ROSflight communicates via the onboard computer with a rosflight_io that publishes to the /command topic.
    2. However this can be accepted and processed only if the drone is armed, for which there has to be a RC feed, or at least something that publishes to the /RC_raw topic.
    3. If /RC_raw topic ceases, then ROSflight goes into failsafe?
    4. What happens if this happens mid-air? Does the whole thing just stop spinning while it goes into Error?
    5. Theoretically, I could emulate RC on my onboard computer and still publish to /command? Would that mean that I would have a "manual" flight mode (RC) and an assisted flight mode /command? In that case would it be reasonable that I rewrite Failsafe as a drone hover/loiter?

    I know these are a lot of questions, partly because I was not able yet to get my joystick running :) I'll give some updates as soon as I get that going in SITL. If someone could give info about any of the preceding points, I would greatly appreciate!

  • Hi @arta, not quite. The /rc_raw topic actually goes the other direction; it is published by rosflight_io to let you know what values the flight controller is getting from the receiver.

    The data flow looks like this:
    rc_mavlink_flow

    So to summarize, you have to supply RC via a transmitter and receiver, which the flight controller forwards to rosflight_io over MAVLink, then rosflight_io publishes the /rc_raw topic to report to you what those values are. If you want the computer to tell the flight controller what to do, you need to publish something to the /command topic, which rosflight_io then forwards to the flight controller via MAVLink.

    If the RC connection is lost while the flight controller is disarmed, it will go into an error state and not allow you to arm until the connection is restored. If the connection is lost while armed, it will go into failsafe mode. This is described here. While in failsafe mode the flight controller commands level flight with the throttle value defined by the FAILSAFE_THR parameter.

    Does that help to clear things up?

    (Since you mentioned SITL, I'll make one note here. Since you can't have a physical RC receiver connected, Gazebo exposes the topic multirotor/RC to which you can publish rosflight_msgs/RCRaw messages to emulate a physical RC connection. This is described here, but applies only to SITL, not hardware. In hardware you still have to have a physical RC receiver attached to the flight controller.)

  • Thank you a lot for the clarifications! It does help actually. Yeah I did read all of the docs, but sometimes I read and it makes sense but still dont really understand. Your explanations cleared things up.

Sign In or Register to comment.