Quirky addVariable snag on basic graph build

[dehann]

Criteria

• Resolve with dispatch as part of DFG v1 (there should be only one signature, regardless if using in-memory or network)

Description

using NavAbilitySDK
using RoME

fg = NavAbilityDFG(auth_token, fglb, aglb; apiUrl, orgLabel=orlb, addAgentIfAbsent=false, addGraphIfAbsent=true)
# NavAbilityDFG{VariableDFG, FactorDFG}
#   FactorGraph: FG_9999
#   Agent: BOT_01
#   BlobStores: [:default]


addVariable!(fg, :x0, Pose2)
# ERROR: type NavAbilityDFG has no field solverParams
# Stacktrace:
#  [1] getproperty
#    @ ./Base.jl:49 [inlined]
#  [2] getSolverParams(dfg::NavAbilityDFG{VariableDFG, FactorDFG})
#    @ DistributedFactorGraphs ~/.julia/packages/DistributedFactorGraphs/lIoPH/src/services/AbstractDFG.jl:98
#  [3] addVariable!(dfg::NavAbilityDFG{VariableDFG, FactorDFG}, label::Symbol, varTypeU::Type{Pose2})
#    @ IncrementalInference ~/.julia/dev/IncrementalInference/src/services/FactorGraph.jl:587
#  [4] top-level scope
#    @ REPL[16]:1

Likely part of the transition period into DFG v1, perhaps there is a temporary workaround that is not too destructive.

---

pre DFG v1 status (FYI dont want to use types as symbols, just the history):

addVariable!(cfg, :x0, :Pose2)
# VariableDFG(UUID("be758c75-2157-5644-bd7d-bc865e2197be"), :x0, [:VARIABLE], TimeZones.ZonedDateTime(2025, 7, 5, 19, 6, 57, 774, tz"Z"), "0", MeanMaxPPE[], BlobEntry[], "Pose2", "0.26.0", "e30=", 1, PackedVariableNodeData[])

---

Aka Violation of Dispatch

• [API Design] dispatch vs verbNoun-verbosity JuliaRobotics/DistributedFactorGraphs.jl#264

[Affie]

For cloud, don't use Symbols :Pose2, it is only left for backward compatibility and will be deprecated, please use:

addVariable!(cloudfg, :x0, NvaSDK.Pose2)

And for local,

using RoME 
addVariable!(localfg, :x0, Pose2)

NvaSDK. is needed for the name conflict until SDK.jl is fully integrated with IIF and RoME Types and no "packed variable types" exists in julia.
After that SDK will become:

using RoMETypes
addVariable!(cloudfg, :x0, Pose2)

Short history:

• Past: SDK.jl didn't look like DFG at all and didn't depend on DFG
• Now: SDK.jl looks like DFG and extends DFG like a driver, but repeats IIF and RoME types and cannot be used with it.
• Future: SDK.jl is just another DFG driver with the only quirk that memory cannot be changed by reference, ie. api calls has to be made to mutate data.

[dehann]

After that SDK will become: RoMETypes.Pose2

yes agree, never meant to use Symbols (bad comms)

[dehann]

closing as regular Q & A issue. Punchline is error above was caused by incorrect dispatch during transition period. In the future everybody should just use e.g. RoMETypes.Pose2 and all the current work on DFG v1.0 and SDK etc will resolve via dispatch or verbNoun-verbosity.