Skip to content

Figures for autonomous driving papers

You are writing a self-driving, autonomous-driving (AD), or ADAS paper — a workshop submission, an IEEE journal piece, an arXiv preprint, a thesis chapter — and you need a figure of a driving scene. Maybe a lane-merge corner case for your prediction work. Maybe an unprotected left turn for your planner. Maybe a pedestrian crossing scenario for your perception evaluation.

The figure has to be:

  • Clean — no irrelevant background, no proprietary-looking simulator screenshot.
  • Scalable — vector, not a pixelated PNG.
  • Editable later — when reviewers ask for a variant, the figure should update without redrawing from scratch.

This is one of the things drawtonomy is reasonably good at.

Where drawtonomy fits among the alternatives

Section titled “Where drawtonomy fits among the alternatives”

Each of these tools is excellent at what it’s designed for, and many great paper figures are produced with them every day. drawtonomy is shaped for a particular combination — a domain-aware 2D canvas with lane / vehicle / pedestrian shapes that stays editable for revisions.

  • PowerPoint / Keynote are the universal choice for figures across all fields, and a lot of clean paper figures come out of them. They’re general-purpose, so road geometry is drawn from primitive shapes rather than built-in lane semantics.
  • Excalidraw / tldraw are excellent whiteboards with a great UX. They focus on generic diagramming rather than domain-specific shapes, so lane direction, connections, and dashed markings are typically drawn by hand.
  • CARLA / SUMO screenshots are the natural choice when the figure should reflect the actual simulator the work runs on — for example, “evaluated on these scenes” appendix figures. They carry simulator visual style, which is appropriate for that purpose and sometimes less ideal for schematic figures in the main text.
  • TikZ in LaTeX is the gold standard for fully precise, LaTeX-native figures, and many beautifully crafted figures use it. The trade-off is the compile-iterate loop, which is longer per figure than a direct-manipulation canvas.

drawtonomy sits between a slide tool and TikZ: a 2D canvas with built-in lane / vehicle / pedestrian shapes. If your workflow already produces great figures with one of the above, the existing toolchain is fine; drawtonomy is most useful when you want domain-aware shapes and re-editability in one editable file.

  1. Sketch the lanes with the Lane Tool. Click the centerline; drawtonomy auto-generates left and right boundaries. For lane merges, draw the merging lane separately and connect its predecessor / successor with Next Lane.
  2. Place participants. Vehicles, pedestrians, traffic lights, and crosswalks live in the toolbar. Drag them onto the canvas.
  3. Indicate motion. Use Path arrows (Arrow style for clean schematics, Band style for emphasising a corridor) to show intended trajectories.
  4. Style for grayscale. Many journals still print in grayscale. The Attribute Panel lets you set color, opacity, and stroke separately so you can pick a palette that survives a grayscale conversion.
  5. Save as .drawtonomy.svg (drawtonomy’s native SVG format). This is the format to reach for by default. It’s a regular SVG, so LaTeX, browsers, GitHub, Markdown, and slide tools all preview it correctly without any conversion. And it’s also re-editable in drawtonomy — when a reviewer asks for “the same figure but with three lanes instead of two”, you reopen the saved file, change two things, and re-export. No redrawing.
  6. Export a raster asset only when needed. If your venue insists on PNG (or you need a thumbnail), export PNG with a high-DPI setting from the same scene. Keep the .drawtonomy.svg source file as the editable source of truth either way.

A .drawtonomy.svg file is a valid SVG with extra metadata, so the LaTeX paths that work for any other SVG also work here. A few practical notes:

  • \includegraphics{} via the svg package. Include the file directly as \includegraphics[width=\linewidth]{your-figure.drawtonomy.svg}. The svg package + inkscape toolchain works but is finicky on CI. For predictable builds, convert to PDF once locally (inkscape --export-type=pdf your-figure.drawtonomy.svg) and \includegraphics{} the resulting PDF.
  • Fonts. Set the xelatex engine if your figure has fonts outside the standard set; otherwise the safe path is “no text in the SVG, all text in the LaTeX caption.”
  • Submission packaging. Many venues want the included graphic as .pdf or .eps. Convert your .drawtonomy.svg → PDF / EPS at submission time, but keep the .drawtonomy.svg file in your repo as the editable source for revisions.

For figures that go into both the paper and the slides:

  • Keep the .drawtonomy.svg file as the single source. Re-export .pdf for the paper if your build requires it, and .png (transparent background) for slides. The same file reopens for the next revision.
  • For photorealistic figures (sensor renderings, neural-rendering results), keep using your simulator screenshot pipeline.
  • For dense urban networks, drawtonomy will run out of steam — use a real HD-map tool.
  • For highly stylised illustrations (cover art, glossy marketing), Illustrator or Affinity will give you more typographic control.