Global Satellite Telemetry for ArduPilot

Blog
,
1

SPL global telemetry
spl.jpg972Ă—584 72.8 KB

SPL is a global satellite telemetry solution for unmanned vehicles controlled by ArduPilot.

With SPL you can:

  • Track position, attitude, and velocity of your vehicles anywhere on Earth.
  • Monitor vital signs of your vehicles, such as battery charge, system status, and temperature.
  • Update on-board parameters and send commands and missions to your vehicles.
  • Control gymbals, and RC servos connected to autopilots.

    • SPL can also be used together with radio telemetry as a long range backup channel to track and control vehicles if they leave radio channel range.

    Essentially, with SPL you could control your unmanned vehicle on the other side of the Earth almost the same way you would with radio telemetry. SPL was designed to work with popular ground control stations such as Mission Planner, QGrouindControl, and MAVProxy.

    SPL uses Iridium short burst data (SBD) satellite communication technology provided by Rock Seven Mobile.

    Iridium SBD is a high latency, low bandwidth messaging technology, yet it is relatively inexpensive compared to other global communication solutions. The required hardware is very compact and lightweight.

    Not only does SPL transmit messages between autopilot and ground control stations, it also filters messages and aggregates data to adapt MAVLink protocol for high latency asynchronous SBD communication.

    The SPL software suite consists of an Arduino sketch called SPL Radio Room for ArduPilot companion computer and a web service application called SPL Ground Control, which serves as a proxy between ground control stations such as Mission Planer or QGroundControl and Rock7Core web services. SPL Radio Room and SPL Ground Control are open source software.

    SPL Radio Room requires the following hardware components:

  • RockBLOCK Mk2 Iridium satellite communication module

  • Arduino 101 or Arduino Mega board

  • An ArduPilot or PX4 autopilot, such as Pixhawk

    • SPLRadioRoom could also work with RockBLOCK+ and RockFLEET modules if additional RS-232 Arduino shield are used.

    RockBLOCK MK2 naked communication module costs around 250$. RockBLOCK line rental is about $13 per month. Arduino 101 is around $30.

    By default SPL Radio Room reports every 15 minutes. Each report costs 1 RockBLOCK credit. The cost of credits varies from $0.05 to $0.14 depending on the amount of credits purchased.

    SPL Ground Control requires a computer accessible over the Internet.
    Running SPL Ground Control on Amazon AWS is probably the easiest way to get started with SPL.

    SPLStream and SPLTracks web services provide a solution for storing and visualizing data reported by SPLRadioRoom.

    Envirover is also working on solutions for saving, mapping, and processing the reported data as well as researching high-bandwidth satellite communication technologies.

    8 Likes
    2

    Very nice! Thank you for sharing Pavel!

    This is very opportune for the upcoming UAV challenge etc. as it solves some issues with long range BLOS comms.

    3

    Nice system!

    I suspect the latency could be an issue for those wanting real-time command and control. Would be useful for slow-moving vehicles where real-time control/command is not required though.

    The cheap “SBD” systems that satellite communications providers offer are primarily based on tracking vehicles, hikers, oil pipelines, etc for occasional status updates. They’re small and cheap.

    Low latency (<5sec) is a different proposition. Requires a much more expensive system. I’ve been waiting for the size/cost of those system to come down to hobbyist levels - getting closer :slight_smile:

    4

    It can work for all vehicles. The main problem is the bit rate is EXTREMELY low. Here’s the MAVlink packet for it:
    https://github.com/mavlink/mavlink/blob/master/message_definitions/v1.0/common.xml#L3821

    It’s not supported in ArduPilot right now but its on the TODO list. There has been very little interest in it so it’s a low priority

    1 Like
    5

    SPL was originally designed for autonomous solar-powered USVs. Low latency is not required for tracking and simple control of such vehicles, and Iridium SBD is good enough for this.

    Yet SBD is not practical for transferring audio, photo, video, and other relatively large data from the vehicles. If there is an affordable way to send a picture from the middle of the ocean, let me know, I’m in.

    6

    Internally SPL does use HIGH_LATENCY MAVLink messages.

    SPL Radio Room reads MAVLink messages from the ArduPilot’s telemetry serial port, integrates high-frequency messages (SYS_STATUS, GPS_RAW_INT, ATTITUDE, GLOBAL_POSITION_INT, MISSION_CURRENT, NAV_CONTROLLER_OUTPUT, and VFR_HUD) into HIGH_LATENCY message and periodically sends the HIGH_LATENCY messages to the ISBD.

    SPL Ground Control receives HIGH_LATENCY messages from ISBD, splits them into the the original set of high-frequency messages and periodically (1Hz) sends them to the GCS along with HEARTBEAT messages.

    7

    Hi,

    i think that is indeed interesting for BLOS use cases where the autonomy
    of the device is good and reliable (thus no RC needed) but regular telemetry is out of range.

    I’d be interested to understand what the “real” realistic update frequency would be that can be achieved though via this service?

    Chris

    8

    While I agree that the latency is a issue for real-time flight control, I imagine that this is still useful for aircraft in the UAV challenge in that there is no consequence for having a high latency “continuous” communications link back to the base GCS or even a complete loss of comms. It’s also “safe” to use whilst the aircraft is on the ground, as the aircraft is not airborne and subject to the CASA requirements for comms to maintain flight control. The worst that can happen is that there is a delay in transmission back to base, seeing that with the type 2 autonomy “no hands rule” the aircraft is no longer required to be commanded to takeoff from the GCS, as was previously the case in 2016, and is now allowed to autonomously takeoff 1 minute after Joe arms the aircraft on the ground.

    For the 2016 event we tried to get approval for operating under the type 2 definition, in that the aircraft would takeoff 1 minute after Joe armed it without a link to the GCS at base, then hover until it regained RF comms to base, failing which it would automatically land again and abort the mission. The result of the request was that type 2 aircraft were no longer allowed in 2016. For 2018 type 2 has a new definition (no hands rule) which essentially makes it possible to operate like that provided a safety case can be made.

    9

    Is it possible to customize the mavlink messages further and reduce them to only to GPS location, altitude airspeed and heading? Maybe with intermittent every minute battery status, arm state and flight mode info? If so I think that there would be a few teams using Ardupilot and sat comms for the OBC that might be interested in it’s further development. (including us of course!) :slight_smile: It might also be helpful for LoRa use?

    From my perspective if the FC is controlling the aircraft autonomously at beyond line of sight range, there are not many options for the user to recover the aircraft in time from a fail state where the FC is required to fly the aircraft, even with real time telemetry available. If the aircraft is operating in line of sight then RFD comms will work and sat comms is not really required in most of those cases anyway, and the user/pilot can resort back to RC control for recovery as well even if the FC fails.

    Overall I think that this type of high latency sat comms system can add value for BLOS aircraft and vehicle comms, so having a configurable mavlink message payload would be ideal to leverage the most from it.

    10

    With good antenna and clear view of the sky from horizon to horizon, I believe the latency of SBD would be around 1 minute. In my tests I used RockBLOCK with patch antenna, and view of the sky was obstructed by buildings and mountains.

    In my tests the signal quality reported by the transceiver varied significantly over time. When the signal quality was high, the transceiver made one or two send/receive sessions per minute. Yet sometimes there were gaps when the signal quality was zero and all the send/receive sessions failed for about 10 minutes.

    Here are a few things to consider:

    • The Iridium satellites are not geostationary. They move from pole to pole with about 100 minutes period.
    • Some of the satellites in the constellation are out of service.
    • Iridium is currently replacing the 20 years old satellites by the new Iridium NEXT constellation.
    • Here is a more detailed research on MEASURING LATENCY IN IRIDIUM SATELLITE CONSTELLATION DATA SERVICES
    11

    Rock7Mobile charges the same price for 1 byte or 50 bytes sent or received.

    “Credits are used each time you transmit. 1 credit is used per 50 bytes (or part thereof) of message sent or received. 1 credit is also used if you check your mailbox and there are no messages waiting (A mailbox check).”

    HIGH_LATENCY message is 48 bytes long, which is fairly close to the optimal 50 bytes.

    We could argue what information is the most important in most of the use cases and should be included in those 50 bytes, but it does not make sense to report less than 50 bytes.

    12

    Thanks for the extra information Pavel.

    I already knew of the 50byte message length limit but was unaware that the HIGH_LATENCY message already fit into it. The messages I listed are the minimum required for the challenge, but not necessarily all the ones i would like to have. I completely agree the Iridium message should contain as much information as it can hold. Having a flexible size message and being able to prioritize and sporadically send information would allow for greater flexibility I think for adopting other systems. For example getting constant battery messages every time does not add much value to operations, instead a battery depleting beyond expected range when it occurs would suffice. As you would probably agree with, not all systems have the luxury of real-time communication, and at some point the autopilot will need to be relied on to overcome issues without the users input or help. In fact the type 2 challenge is exactly that with the no-hands rule, the only issue is the organisers still want to have regular updates on the aircraft, which is fair enough.

    This of course all depends on how the messages are dealt with in the Iridium network itself. From what I understand Iridium is providing a message service, and not providing a “sat comms RF link” as such at all. I’m assuming that Iridium system constantly retries to send a message and only charges for the delivery of the message? That means there is a high probability that the message will be delivered eventually, and when it is, it will be completely intact? So although the latency might be high the message quality is also high, when it is eventually delivered.

    With the latency, is the 10 minute delay the highest you have experienced? Also are you using an external antenna or the built in patch? Do you think it is reasonable to assume that 1-3minute intervals are achievable, and that 10minutes only occurs when there are no satellites overhead? 10 minutes is a bit long, but worse case still within the time limit of the competition at the cost of a few points.

    13

    I’m using RockBLOCK with patch antenna, no external one. The highest latency about 30 minutes I experienced when I forgot to turn off the system and left it in the garage. When the transceiver sees the sky, 10 minutes was probably the worst case. However, I did not deliberately try to achieve the lowest possible latency. Usually I set the reporting period to 15 minutes. This is frequent enough for my use case. So far I don’t have better statistics.

    When messages are delivered, they are delivered intact. That Iridium guarantees. However, the order of messages is not always FIFO. When I sent multiple MT messages in a tight sequence, sometimes the messages are received not in the order they were sent. FIFO order is important for transactions, such as sending missions. To get around the problem I added 10 seconds “spaces” between messages when a sequence of messages is sent. I’m not sure if that will guarantee FIFO order.

    14

    Thanks Pavel.

    It’s good to know that it still works in your garage… :slight_smile:
    Don’t the messages have a time stamp?

    15

    For a lower latency network with good reliability and coverage, INMARSAT is quite good. Or Thuraya if you’re in their coverage zone.

    Could grab one of their phones, strip it down and use the ~5kbps datalink on them. That would give <5sec latency for command and control links.

    (My day job is a Satellite Engineer, so all this is quite interesting for me!).

    16

    Huh cool! I didn’t realise that’s what you do Stephen. Now I know who to ask! :slight_smile:

    My comments above were related to using sat comms for the challenge and how they could be implemented despite the high latency. Having a low latency sat comms link would be nice to have but I think it is currently fairly cost prohibitive for day to day operations? 5 sec latency sounds pretty good considering. I’m currently trying to find the easiest way to comply with the rules and stay mission capable, preferably without using a risky relay aircraft. Maybe we should invest and start developing our own ArduSat? :wink:

    17

    Launching a cubesat and using that as a telemetry relay did feature in a recent CanberraUAV meeting … but we don’t have enough money for that :slight_smile:

    One of the teams (Delft) did have a Iridium modem in their UAV (specs at http://mavlab.tudelft.nl/iridium-communication/) in the 2016 UAV Challenge. They did mention semi-regular dropouts though - as they modem needed to handover from one satellite to the next as the satellites flew over.

    INMARSAT doesn’t require satellite handovers, as their satellites sit in GSO orbit (stationary relative to the earth’s surface).

    EDIT:
    In terms of costs, you get hack together a basic low latency link for <$2000 … depend on your definition of low cost! Satellite ground hardware is getting cheaper and cheaper each year.

    18

    Yeah well you just need to find the right sponsor! I think the main issue will be that you’d have to wait some 90 minutes for a few minutes of connection! :slight_smile:

    I actually asked Bart about that recently. They used a more expensive industrial version of the Rockbloc module and seemingly didn’t have many issues with it. They’re also after a Mozzie atm.

    In general I’m not really a fan of satellites for cost/performance. A better option would be a high altitude solar powered persistent drone running Arduplane using mulit-gigabit microwave link…in fact if you do it right like SHARP you could use the microwave energy through a rectenna to power the plane as well! To get around the regs you go out 12NM from the coast until you hit international airspace, which means you can fly up to whatever altitude you like and stay there for however long you want. According to GE you still get LOS comms to Dalby from there…The only thing is it will need to offer a public AP otherwise it would be in trouble with the challenge rules!

    This is also interesting: http://newatlas.com/quantum-entanglement-satellite-distance-record/50071/

    Do you know the longest Arduplane has ever flown? I think PX4 done 81hours once with their solar plane? I’ve been meaning to build my solar X8 for a while now.

    19

    About the UAV Medical Challenge… Why don’t you just use the same communication channel as the “Joe” when he called the abmulance (which is probably a cell phone these days)? What about using a combination of satellite and cellular?

    20

    Joe was in a remote area. Cellular coverage was not guaranteed over the mission area. We had 2 different cellular modems (using different network providers - Telstra and Optus). Each lost signal at some point in the mission, although we did not lose both at the same time.