AMR Navigation Spotlight – Timing and clock synchronisation

The importance of timing and clock synchronisation in AMRs

There are two elements to timing that you need to consider: 

1. Getting all the clocks in your system operating in sync. 
2. Applying a timestamp to the data packets each sensor generates. 

As we’ll come on to in more detail below, the OxTS GAD Interface is designed to take much of the effort out of the timestamping element of the challenge. Essentially, it’s a pre-built interface where you can configure your sensor data – including the timestamp that your sensor attaches to each data packet. 

But first, let’s look at clock synchronisation. As with so many things in this field, there’s a general correlation between accuracy and complexity: the more accurate you need your synchronisation to be, the more complex the work you need to do.

Basic synchronisation: PPS

Pros: Simple to set up, minimises clock drift 

Cons: Additional effort needed to convert PPS to a usable time format 

Pulse per second is an electrical signal that lasts – you guessed it – for one second. Lots of devices output a PPS signal, including our INS devices, and they are very accurate (down to the picosecond depending on the device). 

Transmitting a PPS signal to your sensors allows them to all agree on how long a second lasts; because of this, PPS is great for reducing clock drift. 

The drawback of PPS is that it’s not actually a measure of time. The PPS signal just tells your network that a second has passed (very accurately), and the devices receiving the signal all add that to their total number of seconds that have passed. To use PPS, therefore, you will also need to synchronise every clock on board your AMR when it initialises so that they all give the same time measurement (you can do this via GNSS, the internet, or via a device like an INS). After that, PPS will keep them in sync.

Intermediate synchronisation: NTP

Pros: Relatively simple to set up, better clock synchronisation across the AMR

Cons: Not as precise as PTP, network latency is not accounted for

Network Time Protocol is a method computer networks use to synchronise their clocks. As long as your localisation processor (such as an INS) can act as an NTP server, and the processor in your AMR control stack can act as NTP client, you should be able to synchronise over NTP.

Because this method of synchronisation is done using actual clock data, it’s more versatile than PPS.

However, NTP is an older technology than PTP, and as such isn’t quite as precise: NTP gives you time to the millisecond, while PTP can achieve sub-microsecond precision. Additionally, NTP is a one-way synchronisation, meaning that clients on the network synchronise with an NTP server (such as our INS), which in turn synchronises with a highly accurate time source (GNSS time, usually). Unlike PTP, this means that NTP can’t factor in network latency to its measurements, reducing its accuracy.

Advanced synchronisation: PTP/gPTP

Pros: Sub-microsecond time precision, highly accurate

Cons: Trickiest to set up, gPTP has more stringent hardware requirements

Precision time protocol synchronisation is the gold standard of time synchronization. It’s the most accurate method of synchronising clocks, and it’s able to account for network latency when it calculates timestamps. There are two flavours of PTP: standard PTP, and generalised PTP, or gPTP. gPTP is an extension of PTP, which is better able to handle larger networks and is more resilient to network issues.

The cost of this accuracy, as we’ve said, is the complexity of the setup. PTP takes some work to set up properly, and if you’re using gPTP, you also need to ensure that every component in your network supports gPTP.

So, those are your options for time synchronisation on your AMR. But there is another option for simple networks with low latency – don’t synchronise your clocks at all.

Timestamp on arrival

Pros: Very easy to set up, well-suited to simple networks with low latency

Cons: Not genuine synchronisation, network traffic and latency can affect accuracy

We mentioned above that timestamping is that other part of the timing puzzle – the timestamp is what the processor will use to understand when the data was gathered so it can process each data packet in the correct order. However, you can send a data packet with instructions for the processor to apply its own timestamp when it receives the data. In an OxTS system, for example you can configure localisation data to be timestamped when it arrives at the INS.

Because you don’t need to get the clocks in every device synchronised, this method is very simple and quick to set up. But, because you aren’t synchronising your clocks, this method of timestamping is vulnerable to interference from network latency.

It is possible to account for the latency in your network – but only if that latency is consistent. Given that the traffic on your network is likely to fluctuate depending on what your AMR is doing, in practice your latency is likely to fluctuate, giving you performance issues. That’s why timestamping on arrival is only really practical in simple networks where latency is minimal. If you’re using timestamping on arrival and your robot is moving jerkily, that’s often a sign that you need a better method of time synchronisation.

How OxTS does timing

All our INS devices support PTP and gPTP synchronisation. In most networks, we find that the INS is used as the grandmaster clock because its internal clock is accurate enough for most AMR applications, and is also synchronised with GPS time via GNSS when signal is available. However, our INS can also be a PTP slave if you have a more accurate clock in your network.

Our INS devices can also emit a PPS signal that you can use to synchronise your clocks. Because an INS uses GNSS data for positioning, it can also give you the initial time stamp for all the clocks in your network that’s vital for making PPS sync work. You can even use the INS’ internal time for PPS sync if you’re operating in a GNSS denied area such as a warehouse, and keep everything in sync when you move outside.

The OxTS GAD Interface

The real magic of what we do is in the OxTS GAD Interface. As we mentioned above, it’s a pre-built sensor fusion interface that allows you to configure how localisation data gets sent from your sensors to our INS – including time data. The GAD interface, accessed using the GAD SDK, allows you to set what timestamp you give your data.

If you’ve synchronised the clocks in your network, you can configure your timestamps to be in GPS time, UNIX, or TAI – whatever works for your network.

We also have two methods for timestamping on arrival: void (which applies the INS’ timestamp to the data when it’s received), and latency (which applies the INS’ timestamp plus a defined latency to the data when it’s received).

You’re also free to use different timestamps in your system at the same time. For instance, you could have some simpler sensors use the void timestamp, while more complex sensors are synchronised with the INS and use the GPS timestamp. The whole point of the GAD Interface is to give you flexibility when building your autonomous mobile robot.

Thanks for your time

Hopefully, this blog has given you a good starting point for thinking about how you synchronise the sensors on your AMR.

If you’d like to learn more about what we can currently do for AMR engineers, view our application page.

Alternatively, if you’ve got a specific project that you’d like to talk to us about, contact us using the form below to get in touch. We’re always keen to help.

Keep an eye out for the next blog in our series: interfacing with the robot.