Почему запись ROSBag записывает только десять событий в секунду с любого датчика?

Я подозреваю, что это скорее функция ограничителя времени (например, частота, передаваемая обратному вызову таймера, который выполняет запись, как вы могли ожидать), на самом деле это узкое место буфера.

Он принимает столько данных для записи на диск или данных в абонентских буферах, прежде чем будет отбрасывать кадры для записи или обработки уже имеющихся данных.

Помимо написания собственного узла с использованием их API C++ и профилирования самой проблемы (также допустимый и не слишком сложный вариант, если он очень необходим), есть некоторые встроенные параметры командной строки, которые управляют размерами буфера (ниже выделено мной).

Я также рекомендую рассчитать желаемую скорость записи в кбит/с; если вы знаете размер одного лидарного сообщения, сколько вы хотите сохранить, и скорость их генерации (rostopic hz/rostopic bw), чтобы дать вам хорошую оценку того, что вы на самом деле спрашиваете.

-b SIZE, --buffsize=SIZE

Используйте внутренний буфер SIZE МБ (по умолчанию: 256, 0 = бесконечный). Это очередь сообщений объекта записи до того, как сообщения будут переданы в сумку. Уменьшение этого значения может привести к удалению сообщений до того, как они достигнут процесса записи.

$ rosbag record -b 1024 /chatter

--chunksize=SIZE

Передовой. Запись фрагментами размером SIZE КБ (по умолчанию: 768). Это буфер в объекте файла пакета. Уменьшение этого значения приведет к большему количеству операций записи на диск.

$ rosbag record --chunksize=1024 /chatter

http://wiki.ros.org/rosbag/Commandline#record

Правки из комментариев:

Два вышеуказанных параметра влияют на буферы сериализованных сообщений, когда необработанное сообщение темы преобразуется в текст и сохраняется. Если они превышены, должен быть ROS_WARN msgs в вашем терминале. (Если нет, вы можете включить их.)

Если вы не видите никаких сообщений ROS_WARN о потерянных кадрах, проблема может заключаться в обычных сообщениях о потерянных ros. Ссылаясь на предыдущие вопросы, вы можете включить статистику темы, чтобы увидеть, не удаляются ли какие-либо сообщения из-за размера очереди. Из исходного кода для инструмента командной строки каждая подписанная тема имеет только буфер сообщений из 100 (ops.queue_size = 100;). Если это проблема, самое простое решение — скопировать исходный пакет из github в вашу рабочую область и изменить размер очереди. Но я подозреваю, что это не настоящая проблема.

Если вы записываете более 10 тем, гипотетически может быть другая проблема, так как по умолчанию это запускает только 10 потоков 'async spinner'; но все другие упомянутые потенциальные проблемы, скорее всего, являются основными причинами.