IEEE TRO | CMU Open-Sources riMESA: Real-Time Multi-Robot SLAM Under Weak Communication and Outliers, 7x+ Ahead on Real Data

The Real Challenge of Multi-Robot SLAM

The hard part of multi-robot SLAM was never "getting several robots to run independently." The genuinely tricky part is this: communication drops, loop closures go wrong, data keeps streaming in — yet every robot must still reach agreement in the same world coordinate frame, and fast.

Daniel McGann and Michael Kaess of the Robotics Institute at Carnegie Mellon University (CMU) have turned riMESA into a system-level solution aimed at real-world deployment, and the work has been accepted to IEEE Transactions on Robotics (TRO). It does not assume a stable network, nor does it hand outlier rejection to a central server. Instead, it combines C-ADMM, the incremental robust optimizer riSAM, asynchronous communication, and failure recovery into a complete distributed C-SLAM backend.

If one sentence had to summarize the paper: the value of riMESA is not "yet another distributed optimizer" — it is the first time the four hardest-to-satisfy-at-once properties of multi-robot SLAM — distributed, incremental, robust, and weak-communication — have been tied together this completely.

The code is open source.

01. Why this work is worth reading: real multi-robot SLAM is not the "ideal network" in papers

Many multi-robot SLAM works quietly assume very comfortable experimental conditions: robots can communicate continuously, data syncs in time, key measurements are mostly reliable, or a time-consuming batch optimization can run in the background. But throw robots into mines, forests, disaster zones, underground spaces, or the lunar surface, and these assumptions collapse simultaneously.

• First, communication is not persistent. Robots usually rely on ad-hoc networks; as distance, occlusion, bandwidth, and interference change, the communication topology keeps changing. Two robots connected right now may not be connected a second later.
• Second, communication is not a reliable transaction. Latency can exceed the sensor update period; links can drop mid-transfer; the paper even highlights the Two-Generals Failure, where only one side believes an exchange succeeded.
• Third, the front-end produces wrong constraints. Run the system long enough and perceptual aliasing, incorrect data association, and false loop closures are almost unavoidable. Plain nonlinear least squares is extremely sensitive to such outliers — a single bad inter-robot loop closure can corrupt the whole graph.
• Fourth, robots cannot wait for optimization to "fully converge" before acting. Planning, navigation, and control need a usable state estimate right now, not a beautiful global map five minutes from now.

This is exactly riMESA's problem setting: robust, real-time, distributed optimization over a continuously growing multi-robot factor graph under ad-hoc, sparse, unreliable, asynchronous communication.

02. Stating the problem: collaborative SLAM is a "distributed MAP with consensus constraints"

The standard single-robot SLAM backend puts all states and measurements into a factor graph and converts maximum a posteriori estimation into a nonlinear least-squares problem. For multi-robot systems, the only difference is that data is no longer centralized: robot $i$ owns only its own subset of states and measurements, yet different robots may observe the same state. Ignoring outliers, the global problem can be written as:

$$\Theta_{\mathrm{MAP}} = \arg\min_{\Theta\in\Omega} \sum_{i\in\mathcal{R}} \sum_{m\in\mathcal{M}_i} \left\|h_m(\Theta_i)-m\right\|_{\Sigma_m}^{2}$$

Here each robot is responsible only for its own measurements; the real trouble is shared states. If robot A and robot B both observe the same pose or landmark, A's copy of that state and B's copy must eventually be equal. So the distributed problem naturally carries consensus constraints:

$$\min_{\{\Theta_i\}} \sum_{i\in\mathcal{R}} f_i(\Theta_i) \quad \mathrm{s.t.}\quad q_s\!\left(\theta_{s_i},\theta_{s_j}\right)=0, \qquad \forall s\in S(i,j)$$

where the function $q$ compares two shared states on their corresponding manifold. This step is crucial, because it explains why the authors bring Consensus ADMM (C-ADMM) into C-SLAM: C-ADMM was built precisely for problems where "each node solves its own local objective but everyone eventually agrees on the shared variables." In other words, riMESA did not first decide "let's use ADMM" and force SLAM into it — the mathematical structure of multi-robot SLAM itself is remarkably close to consensus optimization.

03. From C-ADMM to MESA+: robots solve only their own problem and approach global consensus through communication

3.1 No robot needs to hold the entire global graph

The centralized backend is straightforward: all robots send data to a central server, which computes and broadcasts results. This works well on a stable network, but it brings three problems: high communication volume, a single point of failure, and a global problem that grows with both robot count and run time.

riMESA takes the opposite route: each robot maintains only its local subgraph and builds consensus constraints only on states shared with other robots. C-ADMM introduces an edge variable $z$ and a dual variable $\lambda$ for every robot-to-robot communication edge. Intuitively:

• Local state $\theta$: "where I currently believe this shared state is";
• Edge variable $z$: the intermediate consensus this pair of robots has formed about the shared state;
• Dual variable $\lambda$: a running record of "how far apart we still are," continually pushing both sides toward agreement.

Each communication round therefore transmits neither the whole factor graph nor all raw measurements — only current estimates of shared variables.

3.2 Biased Prior: fitting ADMM consensus back into a standard SLAM solver

One elegant engineering move is the Biased Prior. The local augmented Lagrangian of ADMM contains both a linear dual term and a quadratic penalty term. The authors exploit the equivalence:

$$\arg\min_a \left( \langle b,a\rangle + \frac{\beta}{2}\|a\|^2 \right) = \arg\min_a \frac{\beta}{2} \left\|a+\frac{b}{\beta}\right\|^2$$

so an ADMM constraint that "doesn't look like a SLAM factor" can be rewritten as an ordinary prior factor. Each robot then needs no special optimizer — mature sparse nonlinear frameworks like GTSAM, g2o, and Ceres remain usable. Noting that translation and rotation in a pose have different units and that uniform treatment would under-constrain rotation, the paper uses a Weighted Biased Prior with a noise model, scaling rotation and translation differently.

3.3 Poses live on SE(N) — you cannot simply average vectors

Real SLAM states are not plain Euclidean vectors; poses live on the SE(N) manifold. The authors compared Geodesic, Approximate-Geodesic, Split, and Chordal consensus constraint forms and ultimately adopted the Geodesic constraint. This matches long-standing SLAM experience: for pose optimization, geometric error on the manifold is usually more sensible than "flattening" rotation matrices into vectors. The edge-variable update admits a closed form via pose interpolation:

$$z_{(i,j)s}^{k+1} = \operatorname{SPLIT}\left( \theta_{s_i}^{k+1}, \theta_{s_j}^{k+1}, 0.5 \right)$$

This combination — manifold + edge variables + weighted biased prior + asynchronous edge communication — constitutes MESA+ in the paper. But MESA+ is still essentially a batch consensus optimizer. To truly run on online robots, one more critical step is needed: incrementalization and robustification.

04. First core idea: don't wait for C-ADMM to converge — amortize convergence over robot runtime

Traditional batch distributed optimization falls into a trap: every time new data arrives, all robots must communicate many rounds until the current problem re-converges. That is practically infeasible on real systems.

riMESA's idea is amortization: consensus constraints need not be satisfied all at once right now; they are tightened gradually as future communication opportunities appear. The judgment behind this is pragmatic: an intermediate solution that is not yet strictly globally consistent is still useful. Even if robots are temporarily fully independent, each holds its own local solution; once inter-robot constraints start acting, that solution typically keeps improving. There is no reason to stall the online system just so "this iteration mathematically converges."

In the end, riMESA splits execution into two loops that never deadlock each other:

• Local update: when a new measurement arrives, the robot immediately updates its local state;
• Communication update: whenever two robots can communicate, they update the edge and dual variables associated with their shared states.

Now "how often the network connects" no longer determines "whether SLAM can keep running" — it mainly determines "how fast the robots' agreement improves." This is one of the most engineering-valuable designs in the paper.

05. Second core idea: outliers don't need team-wide adjudication — suppress them locally first

If plain least squares were dropped into the framework above, bad loop closures would still corrupt local solutions and then propagate to other robots through consensus. The authors therefore wrap measurement residuals in a robust kernel:

$$\Theta_{\mathrm{MAP}} = \arg\min_{\{\Theta_i\}} \sum_{i\in\mathcal{R}} \sum_{m\in\mathcal{M}_i} \rho\!\left( \left\|h_m(\Theta_i)-m\right\|_{\Sigma_m}^{2} \right)$$

On the surface this just adds a robust function $\rho$, but for distributed SLAM it means a lot: because the global objective is separable, outlier handling can stay on the robot that produced the measurement. There is no need to ship all raw measurements to a central node for unified outlier screening.

But the authors did not stop at "wrap residuals in a Geman-McClure kernel." Fixed M-estimators are fast but sensitive to initialization — and multi-robot systems frequently suffer poor initialization, noisy loop closures, and weak observations. So riMESA's local solver is riSAM.

riSAM itself is a robust incremental SLAM solver that turns the Graduated Non-Convexity (GNC) continuation idea into an incremental version: instead of facing the strongly non-convex robust objective from the start, optimization gradually reshapes the robust kernel, letting the problem transition from an easier objective to the final strongly robust one. The paper's implementation uses DogLeg line search with the SIG kernel, stepping the control parameter through:

$$\mu = \left[ 0.0,\ 0.5,\ 0.9,\ 0.95,\ 1.0 \right]$$

Thus riMESA keeps both capabilities: incrementality — when new factors arrive, only affected local subproblems are updated; robustness — continuation reduces the fixed robust kernel's dependence on initial values. This is also why kiMESA in the paper — the ablation variant replacing riSAM with iSAM2 + a fixed M-estimator — visibly struggles under high noise.

06. The truly clever step: the "consensus prior" between robots must also be allowed to be questioned

A hidden problem remains. Suppose robot A temporarily forms a wrong belief because of a bad inter-robot loop closure; robot B later gains new local information suggesting the previous consensus may be flawed. If the Biased Prior between the two robots is always treated as absolutely trustworthy, stale consensus can suppress fresh evidence — the system "knows it was wrong, yet cannot easily correct itself."

riMESA's answer: wrap the Biased Prior itself in a robust kernel. The authors call it the Robust Weighted Biased Prior (RWBP). Simplified, the local update reads:

$$\Theta_i^{k+1} = \arg\min_{\Theta_i\in\Omega_i} \sum_{m\in\mathcal{M}_i} \rho\!\left( \left\|h_m(\Theta_i)-m\right\|_{\Sigma_m}^{2} \right) + \sum_j\sum_{s\in S(i,j)} \rho\!\left( \frac{\beta_{(i,j)s}^{k}}{2} \left\| \operatorname{Log}\left( \theta_{s_i}^{k}\ominus z_{(i,j)s}^{k} \right) + \frac{\lambda_{(i,j)s}^{k}}{\beta_{(i,j)s}^{k}} \right\|_{\Sigma_s}^{2} \right)$$

The meaning is plain: if a robot finds that "current consensus seriously conflicts with the new evidence I just got," it can temporarily treat that consensus as outdated information instead of being dragged back into a wrong state. This fits online reality perfectly: the order in which information arrives is unpredictable, and today's "consensus" is not necessarily more trustworthy than tomorrow's new observation.

07. RWBP is not enough: decay the dual variables so historical errors don't accumulate as debt

ADMM dual variables keep accumulating historical disagreement. If a consensus constraint is later rejected by the robust kernel, stale dual variables may still carry large error components. riMESA therefore adds decay to the standard dual update:

$$\lambda_{(i,j)s}^{k+1} = \mathfrak{d}\,\lambda_{(i,j)s}^{k} + \beta_{(i,j)s}^{k}\, q_s\!\left( \theta_{s_i}^{k+1}, z_{(i,j)s}^{k+1} \right), \qquad \mathfrak{d}=0.9$$

In other words, historical constraints are not booked indefinitely; newer information carries more weight. This looks like merely multiplying by 0.9, but the paper's ablations show that together with RWBP it clearly improves riMESA's robustness.

08. Third core idea: decouple the communication thread from the SLAM main thread — a dropped link just discards that exchange

Many "theoretically asynchronous" distributed algorithms still block on communication in practice. riMESA designs a dedicated Communication Handler so that communication happens on an independent thread and operates on a cached copy of the algorithm state. Three benefits:

First, network latency never stalls local state updates

Even if one communication round takes 200 ms and several new sensor frames arrive meanwhile, the main thread keeps updating local state with riSAM.

Second, mid-transfer disconnection never pollutes the main state

A cache copy is made when communication starts. Only if the entire exchange completes successfully is the result merged into the main thread. On timeout or disconnection, the cache is simply discarded. For the SLAM main state, the worst case is "missing one communication opportunity" — never writing half-baked data into the system.

Third, parallel communication comes for free

Robot A can communicate with B while simultaneously opening another exchange with C — no need to wait for all robots to form a synchronized round. The paper further adopts two-phase communication:

• Phase 1: the two sides first exchange "which variables we actually share, which are uninitialized, and which dimensions are locally observable";
• Phase 2: after agreeing on the shared set, they exchange the corresponding state estimates.

This is far cheaper than "sending the whole local solution" and better suited to long runs where the shared-state set keeps changing.

09. An easy-to-miss detail: how shared variables are initialized directly affects outlier identification

Plain C-ADMM is usually insensitive to initialization, but robust estimation is different. If a new shared variable is initialized from just one robot's value, that choice injects bias into the optimizer and can directly affect whether a measurement later gets classified as "inlier" or "outlier."

riMESA therefore designs robust initialization: state components directly observable by local measurements keep local information first; unobservable components are filled in from the state of the robot that "owns" the variable. For example, bearing-range measurements can directly observe relative position but not the other robot's full heading — there is no reason to crudely copy the entire pose; instead, information from different sources is assembled by observability. The paper includes a dedicated ablation: under Range-Only, Bearing-Range, and C-PGO local observability conditions, the full robust initialization scheme performs best overall.

10. riMESA's runtime, strung together, is just three things

From an implementation perspective, riMESA is less mysterious than it looks — it condenses into three main flows.

Flow A: new measurement arrives

The robot determines which local variables, shared variables, and edge variables the new factor involves; creates the corresponding edge variables, dual variables, penalty parameters, and RWBP; then calls riSAM for one incremental update. For RWBPs that have not yet seen a successful exchange with the other robot, the penalty is initialized extremely small:

$$\beta_{\mathrm{uninit}}=10^{-4}$$

so pseudo-priors "without a valid inter-robot state" cannot wrongly influence the current solution. After the first successful communication, it is set to:

$$\beta_{\mathrm{init}}=1.0$$

Flow B: communication opportunity detected

Launch the independent Communication Handler and complete the two-phase information exchange using cached states.

Flow C: communication succeeded

The main thread updates edge and dual variables using exactly the cached values both sides actually transmitted, and marks the related variables for re-elimination and re-convexification in the next riSAM update. If communication fails, Flow C is simply skipped.

This matters: riMESA does not try to "predict whether the network will be reliable" — the algorithm's structure itself accepts an unreliable network.

11. Experiments go beyond C-PGO: the authors deliberately tested many C-SLAM observation structures

The paper's experimental volume is large. The authors report: 2,430 independent synthetic datasets; 28 real-world datasets. Synthetic environments cover 6 robots with different noise levels, observation structures, team sizes, run lengths, and communication qualities; real data uses 24 datasets from COSMO-Bench plus 4 from Nebula.

The most notable thing is not "lots of data" but that the authors refused to reduce C-SLAM to a fixed C-PGO problem. The paper tests:

• Collaborative Pose-Graph Optimization (C-PGO)
• Range-Aided PGO
• Range-Only C-SLAM
• Bearing-Range-Only C-SLAM
• Landmark C-SLAM
• Landmark + Direct C-SLAM
• Full 3D C-PGO without planar constraints

This is why the paper insisted on modeling "general C-SLAM" rather than "pose graphs only" from the start.

12. A key conclusion: riMESA turns communication quality into a degradable variable

The paper does not hide riMESA's weaknesses. In problems with low-rank inter-robot measurements — Range-Aided PGO, Range-Only, Bearing-Range-Only — performance drops noticeably when noise is also large. The authors' analysis shows this is not simply because the robust kernel is too weak: these observations inherently provide little inter-robot geometric information, and sparse communication pushes the effective signal-to-noise ratio even lower.

The authors then ran experiments varying communication conditions step by step — from high latency, small communication range, and low frequency toward low latency, large range, and high frequency. The result is interesting: as communication improves, riMESA's performance in low-SNR scenarios clearly recovers.

This shows riMESA is not claiming "communication doesn't matter at all." The more accurate reading: it turns communication from a "precondition that must always be satisfied" into a continuous resource that affects convergence speed and final quality. That distinction is important.

13. Scalability: trajectories up to 5,000 poses, teams up to 48 robots, and riMESA stays stable

The authors separately tested long runs and team size. In the long-run experiment, 6 robots' trajectory length grew from 500 to 5,000; in the team-size experiment, each robot held 1,000 poses while robot count grew from 3 to 48.

riMESA maintains stable accuracy and outlier classification under these scale changes, while DDF-SAM2 and DLGBP degrade more noticeably as scale grows — DLGBP in particular, constrained by its sliding window, struggles to exploit loop closures spanning long time horizons.

14. Real data is the point: not winning one dataset, but keeping the worst case under control

Real-world experiments use COSMO-Bench and Nebula. COSMO-Bench is built on real LiDAR data, an actual C-SLAM front-end, and communication models drawn from real networks. In experiments, robots attempt communication at 5 Hz with per-exchange latency capped at 200 ms, plus an extra 5% of otherwise-successful exchanges suffering Two-Generals Failure. Qualitatively, point clouds from different robots align well into a single map.

The quantitative results matter more. Rather than cherry-picking the prettiest dataset, the paper computes each method's average performance gap relative to Centralized GNC across all real data:

Method	Average gap relative to Centralized GNC
riMESA	45.09%
kiMESA	157.70%
DLGBP	352.81%
DDF-SAM2	787.30%

The gap is defined as:

$$\operatorname{Gap}(m) = \frac{\text{iATE}_{m}-\text{iATE}_{\mathrm{GNC}}}{\text{iATE}_{\mathrm{GNC}}} \times 100\%$$

By this metric, riMESA's gap to Centralized GNC is over 7× smaller than DLGBP's and over 17× smaller than DDF-SAM2's. This is more meaningful than "ATE dropped by X on some dataset," because Centralized GNC can use centralized data and stronger global robust optimization, while riMESA must work under communication constraints. The paper also shows a vivid time-series case: DDF-SAM2 clearly diverges around 4,200 seconds, while riMESA tracks the Centralized Oracle's error trend throughout.

15. Real-time performance: robust centralized optimization is accurate but can't run online

A multi-robot SLAM backend cannot be judged by final ATE alone — how long each update takes matters too. On main_campus_wifi, the authors measured runtime on an Intel Core i9-13900K with 128 GB RAM, tracking both per-update cost and cumulative time. Results:

• riMESA and most distributed methods maintain real-time operation;
• DDF-SAM2 shows long update times late in the sequence;
• Centralized Oracle stays real-time because it knows which measurements are true inliers;
• but Centralized GNC and Centralized PCM — which must actually handle outliers online — accumulate optimization cost beyond the real-time boundary.

This is the biggest difference between this paper and many "offline global optimization" works: it cares whether robots can keep using the current solution at every moment during operation.

16. Bandwidth measured too: tens of KB/s on average, peaks within the experimental network model's cap

The paper does not hard-cap each communication with a bandwidth limit in the main experiments, but the authors recorded actual communication volume in real-data experiments to verify the assumption is reasonable:

Network model	Peak bandwidth	Average bandwidth
Wi-Fi model	625.3 KB/s	54.9 KB/s
Pro-Radio model	825.3 KB/s	57.6 KB/s

Both stay below the bandwidth caps set for the corresponding network models. In the more extreme ntu_r3_02_wifi experiment, riMESA's peak was only 3.8 KB/s and average just 0.12 KB/s, yet it still beat every compared distributed method and even some centralized ones. This shows that sharing "states" rather than continuously syncing the entire raw factor graph genuinely opens the door to more constrained real networks.

17. What does this paper really contribute? More than a new backend

Strip away the algorithm names and formulas, and riMESA leaves four layers of thought worth taking away.

Layer one: turn "global consistency" from a one-shot goal into a continuous approximation process

The traditional intuition is: once an inter-robot constraint appears, hurry and re-solve the global graph to convergence. riMESA accepts reality instead — as long as the current intermediate solution is useful, consistency may strengthen gradually over many future communications. This brings "online" truly into the distributed optimization structure, rather than simply re-running a batch algorithm over and over.

Layer two: robustness can be solved locally; consensus then propagates in a distributed way

C-ADMM's separable structure lets each robot first judge locally whether measurements are trustworthy, then propagate results through shared states. This decouples "robust estimation" and "multi-robot consensus" from one giant global problem.

Layer three: consensus itself can expire

RWBP is an easily overlooked but beautiful design. Many systems assume information synchronized across robots is inherently more trustworthy, while riMESA lets a robot temporarily reject an old consensus constraint after obtaining new evidence. This fits long-term autonomous systems better: having agreed in the past does not mean the past was forever right.

Layer four: network failures are not an exceptional path — they are normal operating state

The Communication Handler design shows the authors built the algorithm with real-system thinking: latency, disconnections, and half-successful exchanges are not "problems to solve later during engineering" but input conditions the algorithm must face directly.

18. riMESA also has clear boundaries — don't overread the conclusions

18.1 No formal end-to-end convergence guarantee

The paper discusses this explicitly. Variants of C-ADMM have theoretical results for non-convex problems, manifold problems, nonlinear constraints, asynchronous settings, and separable problems respectively — but no existing theorem directly covers C-SLAM, which combines several of these complications with coupled nonlinear constraints. More importantly, riMESA adds communication amortization, RWBP, and dual decay for online operation; these keep the problem itself changing over time, moving further from the standard "ADMM convergence on a fixed objective" setting. riMESA's strength is therefore large-scale empirical validation, not a complete global convergence proof.

18.2 Weak observations + heavy noise + terrible communication is still hard

Low-rank inter-robot constraints like Range-Only inherently lack geometric information under high noise. riMESA tolerating sparse communication does not mean it can conjure high-quality global state from a nearly information-free system. The paper's own experiments show these scenarios improve markedly with more communication.

18.3 "Bandwidth acceptable" is currently measured validation, not strict bandwidth-constrained optimization

The authors recorded bandwidth and showed experimental values fall below the network model's cap, but the main experiments do not explicitly add per-link bandwidth budgets as optimization constraints. For even lower-bandwidth wireless links in the future, there remains plenty of room to further compress shared states and select the most valuable variables to communicate.

19. For SLAM practitioners, what is most worth borrowing from riMESA?

The strongest impression from this paper is how tightly it binds algorithm design to real system constraints. If you only care about single-robot high-precision mapping, C-ADMM may not be what you need most; but once a system enters multi-robot collaboration, the problem shifts instantly from "how do I optimize a factor graph" to:

Who holds what data? Who can talk to whom, and when? How far does a wrong inter-robot constraint propagate? Can the system keep going without communication? Can new evidence overturn old consensus?

riMESA's answers are not complicated, but they are complete in combination: local graphs are solved by a mature incremental optimizer, outliers handled robustly and locally; shared variables reach consensus via C-ADMM; communication advances when opportunities appear and local operation continues otherwise; stale consensus conflicting with new information can be robustly down-weighted.

The value of this thinking actually extends beyond C-SLAM. Any problem where "multiple robots maintain local estimates yet must agree on some shared states over an unstable network" can draw inspiration from this structure.

20. Summary

What riMESA ultimately solves is not the idealized "find the optimum of a multi-robot pose graph" problem, but a combined difficulty much closer to deployment sites: measurements keep arriving, loop closures can be wrong, robots can only occasionally meet to communicate, the network can break — yet the system must always provide state estimates usable for navigation and planning.

Its technical through-line condenses to one sentence: use C-ADMM for inter-robot consensus, use riSAM for local incremental robust optimization, and through RWBP, dual decay, robust initialization, and non-blocking communication, turn the theoretical consensus process into a C-SLAM backend that works online.

Experimentally, riMESA does not "crush everything" under all conditions, but it exhibits the property real systems need most: stability. Some methods excel on certain datasets only to collapse on others; riMESA stands out because across observation types, noise levels, communication qualities, team sizes, and real datasets, its overall behavior stays more controlled. For multi-robot SLAM backends, this "cross-condition stability" often matters more than the lowest ATE on a single dataset.

Paper Information

• Title: riMESA: Consensus ADMM for Real-World Collaborative SLAM
• Authors: Daniel McGann, Michael Kaess
• Affiliation: Robotics Institute, Carnegie Mellon University (CMU)
• Journal: IEEE Transactions on Robotics (TRO)
• Project / Code: github.com/rpl-cmu/rimesa
• riSAM implementation: github.com/rpl-cmu/risam-v2

---

Original source: 智驾机器人技术前线 (WeChat Official Account), published 2026-08-26. This is an academic sharing and full translation.