Why the planning module can't be triggered based on a timer under the Cyber RT framework?

[davidhopper2003]

Under the Cyber RT framework, the update of the planning module is changed from the timer triggering mechanism to the message updating mechanism. In other words, a specific planner such as NaviPlanner of the planning module only works (via planning_base_->RunOnce (local_view_, &adc_trajectory_pb);) in the case where all three messages prediction::PredictionObstacles, canbus::Chassis and localization::LocalizationEstimate have arrived.
It causes a problem for debugging the planning algorithm. Usually, a recorded data bag file only contains two types of messages: canbus::Chassis and localization::LocalizationEstimate; the prediction::PredictionObstacles messages doesn't exist in general. If we start the Perception and Prediction modules to generate such a message, the following core dump message will appear:

#0  0x00007f5437d21c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007f5437d25028 in __GI_abort () at abort.c:89
#2  0x00007f54398e7284 in google::DumpStackTraceAndExit() () from /usr/local/lib/libglog.so.0
#3  0x00007f54398deec0 in google::LogMessage::Fail() () from /usr/local/lib/libglog.so.0
#4  0x00007f54398dee07 in google::LogMessage::SendToLog() () from /usr/local/lib/libglog.so.0
#5  0x00007f54398de7de in google::LogMessage::Flush() () from /usr/local/lib/libglog.so.0
#6  0x00007f54398e183b in google::LogMessageFatal::~LogMessageFatal() () from /usr/local/lib/libglog.so.0
#7  0x00007f54148c159d in apollo::perception::common::SensorManager::SensorManager (this=0x60bb2d0) at modules/perception/common/sensor_manager/sensor_manager.cc:36
#8  0x00007f542a3ec351 in apollo::perception::common::SensorManager::Instance(bool)::{lambda()#1}::operator()() const (__closure=0x7ffc8003528b) at ./modules/perception/common/sensor_manager/sensor_manager.h:86
#9  0x00007f542a3f1c58 in std::_Bind_simple<apollo::perception::common::SensorManager::Instance(bool)::{lambda()#1} ()>::_M_invoke<>(std::_Index_tuple<>) (this=0x7ffc8003528b)
    at /usr/include/c++/4.8/functional:1732
#10 0x00007f542a3f0515 in std::_Bind_simple<apollo::perception::common::SensorManager::Instance(bool)::{lambda()#1} ()>::operator()() (this=0x7ffc8003528b) at /usr/include/c++/4.8/functional:1720
#11 0x00007f542a3ee6f2 in std::__once_call_impl<std::_Bind_simple<apollo::perception::common::SensorManager::Instance(bool)::{lambda()#1} ()> >() () at /usr/include/c++/4.8/mutex:754
#12 0x00007f54388e1a80 in pthread_once () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_once.S:103
#13 0x00007f542a3e82c2 in __gthread_once (__once=0x7f542a7f4178 <apollo::perception::common::SensorManager::Instance(bool)::flag>, __func=0x7f543837b110 <__once_proxy>)
    at /usr/include/x86_64-linux-gnu/c++/4.8/bits/gthr-default.h:699
#14 0x00007f542a3ed257 in std::call_once<apollo::perception::common::SensorManager::Instance(bool)::{lambda()#1}>(std::once_flag&, apollo::perception::common::SensorManager::Instance(bool)::{lambda()#1}&&) (
    __once=..., 
    __f=<unknown type in /apollo/bazel-bin/modules/perception/onboard/component/../../../../_solib_k8/libmodules_Sperception_Sonboard_Scomponent_Slibperception_Ucomponent_Uinner_Ulidar.so, CU 0x68780e, DIE 0x84c375>) at /usr/include/c++/4.8/mutex:786
#15 0x00007f542a3ec3d6 in apollo::perception::common::SensorManager::Instance (create_if_needed=true) at ./modules/perception/common/sensor_manager/sensor_manager.h:86
#16 0x00007f542a3e8c99 in apollo::perception::onboard::SegmentationComponent::InitAlgorithmPlugin (this=0x5a2a330) at modules/perception/onboard/component/segmentation_component.cc:73
#17 0x00007f542a3e8877 in apollo::perception::onboard::SegmentationComponent::Init (this=0x5a2a330) at modules/perception/onboard/component/segmentation_component.cc:48
#18 0x00007f542a3fef85 in apollo::cyber::Component<apollo::drivers::PointCloud, apollo::cyber::NullType, apollo::cyber::NullType, apollo::cyber::NullType>::Initialize (this=0x5a2a330, config=...)
    at ./cyber/component/component.h:138
#19 0x0000000000413484 in apollo::cyber::mainboard::ModuleController::LoadModule (this=0x7ffc80035920, dag_config=...) at cyber/mainboard/module_controller.cc:99
#20 0x00000000004138b2 in apollo::cyber::mainboard::ModuleController::LoadModule (this=0x7ffc80035920, path="/apollo/modules/perception/production/dag/dag_streaming_perception.dag")
    at cyber/mainboard/module_controller.cc:128
#21 0x0000000000412eca in apollo::cyber::mainboard::ModuleController::LoadAll (this=0x7ffc80035920) at cyber/mainboard/module_controller.cc:64
#22 0x0000000000412ad4 in apollo::cyber::mainboard::ModuleController::Init (this=0x7ffc80035920) at cyber/mainboard/module_controller.cc:33
#23 0x000000000040f462 in main (argc=3, argv=0x7ffc80035ad8) at cyber/mainboard/mainboard.cc:41

Why the planning module can't be triggered based on a timer to facilitate the debugging of a specific planning algorithm?

System information

• OS Platform and Distribution (e.g., Linux Ubuntu 14.04): Linux Ubuntu 16.04
• Apollo installed from (source or binary): source
• Apollo version (1.0, 1.5, 2.0, 2.5, 3.0): 3.5

[lianglia-apollo]

We are using data to trigger each module to minimize the end-to-end time delay. You can add a dummy prediction to provide some prediction topic so that the planning can be triggered.

[davidhopper2003]

@lianglia-apollo I've got it. Thank you very much.

[natashadsouza]

Closing this issue as it appears to be resolved. @davidhopper2003 feel free to reopen it if you have additional questions. Thanks!

[yfzhang]

@lianglia-apollo , previously with the timer-trigger scheme, if the perception/prediction module gets stuck, planner module can still compute the trajectory using the latest localization data. Now we lose this property with the new data-trigger design. How do you consider this problem when you make this design change?