Class BatchOptimizer

Nested Relationships

Nested Types

Inheritance Relationships

Base Type

Class Documentation

class BatchOptimizer : public fuse_optimizers::Optimizer

A simple optimizer implementation that uses batch optimization.

The batch optimization takes place in a separate thread. Received sensor transactions are queued while the optimization is processing, then applied to the graph at the start of the next optimization cycle. Optimization cycles are started at a fixed frequency. If the previous optimization is not yet complete when the optimization period elapses, then a new optimization will not be started. The previous optimization will run to completion, and the next optimization will not begin until the next scheduled optimization period. For batch optimization problems that continuously grow in size, this means that the optimization period is not overly important. The time spent waiting versus the time spent optimizing will approach zero as the problem size increases.

Parameters:

  • motion_models (struct array) The set of motion model plugins to load

    - name: string  (A unique name for this motion model)
      type: string  (The plugin loader class string for the desired motion model type)
    - ...
    

  • optimization_period (float, default: 10.0) The minimum time delay, in seconds, between optimization cycles.

  • publishers (struct array) The set of publisher plugins to load

    - name: string  (A unique name for this publisher)
      type: string  (The plugin loader class string for the desired publisher type)
    - ...
    

  • sensor_models (struct array) The set of sensor model plugins to load

    - name: string  (A unique name for this sensor model)
      type: string  (The plugin loader class string for the desired sensor model type)
      motion_models: [name1, name2, ...]  (An optional list of motion model names that should be
                                           applied)
    - ...
    

  • transaction_timeout (float, default: 10.0) The maximum time to wait for motion models to be generated for a received transactions. Transactions are processes sequentially, so no new transactions will be added to the graph while waiting for motion models to be generated. Once the timeout expires, that transaction will be deleted from the queue.

Public Types

using ParameterType = BatchOptimizerParams

Public Functions

BatchOptimizer(fuse_core::node_interfaces::NodeInterfaces<ALL_FUSE_CORE_NODE_INTERFACES> interfaces, fuse_core::Graph::UniquePtr graph = nullptr)

Constructor.

Parameters:
  • interfaces[in] The node interfaces for the node driving the optimizer

  • graph[in] The graph used with the optimizer

virtual ~BatchOptimizer()

Destructor.

Protected Types

using TransactionQueue = std::multimap<rclcpp::Time, TransactionQueueElement>

Queue of Transaction objects, sorted by timestamp.

Note: Because the queue is sorted on insert, the insert operation is O(logN). However, it is far more likely that the computer will run out of memory before the insertion time grows large enough to surpass the sensor update period.

Protected Functions

void applyMotionModelsToQueue()

Generate motion model constraints for pending transactions.

Transactions are processed sequentially based on timestamp. If motion models are successfully generated for a pending transactions, that transaction is merged into the combined_transaction_ variable and removed from the pending queue. If motion models fail to generate after the configured transaction_timeout_, the transaction will be deleted from the pending queue and a warning will be displayed.

void optimizationLoop()

Function that optimizes all constraints, designed to be run in a separate thread.

This function waits for an optimization or shutdown signal, then either calls optimize() or exits appropriately.

void optimizerTimerCallback()

Callback fired at a fixed frequency to trigger a new optimization cycle.

This callback checks if a current optimization cycle is still running. If not, a new optimization cycle is started. If so, we simply wait for the next timer event to start another optimization cycle.

virtual void transactionCallback(const std::string &sensor_name, fuse_core::Transaction::SharedPtr transaction) override

Callback fired every time the SensorModel plugin creates a new transaction.

This callback is responsible for ensuring all associated motion models are applied before any other processing takes place. See Optimizer::applyMotionModels() for a helper function that does just that.

This implementation shares ownership of the transaction object.

Parameters:
  • name[in] The name of the sensor that produced the Transaction

  • stamps[in] Any timestamps associated with the added variables. These are sent to the motion models to generate connected constraints.

  • transaction[in] The populated Transaction object created by the loaded SensorModel plugin

virtual void setDiagnostics(diagnostic_updater::DiagnosticStatusWrapper &status) override

Update and publish diagnotics.

Parameters:

status[in] The diagnostic status

Protected Attributes

fuse_core::Transaction::SharedPtr combined_transaction_

Transaction used aggregate constraints and variables from multiple sensors and motions models before being applied to the graph.

std::mutex combined_transaction_mutex_

Synchronize access to the combined transaction across different threads

ParameterType params_

Configuration settings for this optimizer.

std::atomic<bool> optimization_request_

Flag to trigger a new optimization.

std::condition_variable optimization_requested_

Condition variable used by the optimization thread to wait until a new optimization is requested by the main thread

std::mutex optimization_requested_mutex_

Required condition variable mutex.

std::thread optimization_thread_

Thread used to run the optimizer as a background process.

rclcpp::TimerBase::SharedPtr optimize_timer_

Trigger an optimization operation at a fixed frequency

TransactionQueue pending_transactions_

The set of received transactions that have not been added to the optimizer yet. Transactions are added by the main thread, and removed and processed by the optimization thread.

std::mutex pending_transactions_mutex_

Synchronize modification of the pending_transactions_ container

rclcpp::Time start_time_

The timestamp of the first ignition sensor transaction.

bool started_

Flag indicating the optimizer is ready/has received a transaction from an ignition sensor

struct TransactionQueueElement

Structure containing the information required to process a transaction after it was received.

Public Functions

inline TransactionQueueElement(const std::string &sensor_name, fuse_core::Transaction::SharedPtr transaction)

Public Members

std::string sensor_name
fuse_core::Transaction::SharedPtr transaction