search

tud-hri / joan

JOAN is an software package that allows to perform human-in-the loop experiments in the open source driving simulator CARLA. JOAN facilitates communication between human input devices and CARLA, the implementation of haptic feedback, systematically storing experiment data, and the automatic execution of experiments with multiple experimental conditions.
Other
11 stars 7 forks source link

RuntimeError: Spawn failed because of collision at spawn position #2

Closed asevenster closed 3 years ago

asevenster commented 3 years ago

When the following error occurs RuntimeError: Spawn failed because of collision at spawn position JOAN freezes and you have to restart the program and your experiment. image

OlgerSiebinga commented 3 years ago

This seems to be a generic problem with all JOAN modules. If an exception occurs in the get_ready() function of a module, the except_hook is called but the process is not terminated correctly. But I'm not sure what exactly is happening.

niekbeckers commented 3 years ago

On top of Olger's answer - the origin of the problem is that CARLA tries to spawn a car on top of another already existing car. The existing car is there because a) CARLA hasn't disposed of it properly, b) JOAN hasn't disposed of the car properly (e.g. due to a crash of JOAN).

One approach is to check what cars are already spawned in CARLA before spawning new cars to avoid this issue.

On Thu, Jul 1, 2021 at 1:07 PM Olger Siebinga @.***> wrote:

This seems to be a generic problem with all JOAN modules. If an exception occurs in the get_ready() function of a module, the except_hook is called but the process is not terminated correctly. But I'm not sure what exactly is happening.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tud-hri/joan/issues/2#issuecomment-872147014, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACZPCYY4YUGHHILLW3JNXVLTVRD6XANCNFSM46NPFJWQ .

OlgerSiebinga commented 3 years ago

Turns out the module manager got stuck in an infinite loop because it was waiting for the get_ready() function to trigger the module_is_ready event. The excepthook exited the process before this event was set, causing the module manager to hang. This issue was fixed in commit a99a02238ae879a7cb4c89bdddb8e7a329de5996 by setting the event from the excepthook before exiting.