Event skipping to end

[Rebecca-iRobot]

When a bump event is triggered, the robot drives backward about .5 cm and then skips to set_speeds.

`await robot.set_speeds(10, 10)

@robot.on_bump()
async def any_bumps(bumper: Bumper):
print(f"any_bumps: {bumper}")
await robot.drive_distance(-10)
await robot.turn_left(180)
await robot.set_speeds(10, 10)`

[mogenson]

Hi Rebecca!

Interesting bug you found.

Here's a smaller example that demonstrates the same behavior:

@robot.on_bump()
async def bump_event(_bumper):
    await robot.drive_distance(10)
    await robot.set_speeds(10, 10)

Looks like this is happening because there's an event fired for bumper pressed, and a second event fired for bumper released. The first event is still running when the second one starts so the following happens:

1. 1st bump event
2. send drive distance command 1
3. 2nd bump event
4. send drive distance command 2
5. receive drive distance 1 finished (because it was interrupted by drive 2)
6. 1st bump event moves on and sends set speeds 1 command
7. receive drive distance 2 finished (because it was interrupted by set speeds 1)
8. 2nd bump event moves on and sends set speeds 2 command

The result is the robot running the final set speeds 2 command.

You can add a filter, like: @robot.on_bump(filter=Bumper(left=True, right=False)). But this behavior will still happen if you quickly double-tap the bumper.

I think I need to stop previously running events before starting a new event. The question is which running events to stop. Stop all events for the same sensor? That would have a left bumper event cancel a previously running right bumper event. Maybe stop all previous events with the same sensor and filter. This would allow independent left bumper and right bumper events to keep running, but prevent the double trigger behavior reported here.

[mogenson]

I did the easy thing first and made a new event cancel all previously running events for the same sensor. I pushed an update to root-robot-python.web.app. Let me know if the new behavior works for you (you may need to clear cookies/cache to get the new version).

[miniBloq]

What the iRobot Coding app does for these cases is:

1. It never re-triggers an event that is currently running. The system keeps track of events that are running (which may be multiple ones) and they can not be triggered again until they are marked as stopped (by reaching their last instruction). If they contain any infinite loop, they will never re-trigger.

2. In the specific case of bumpers, we filter-out the release-events, only detecting the push event (kind of rising edge detection on a square signal).

[mogenson]

Hi!

Masking a new event while a previous event is running seems just as reasonable as canceling a previously running event. What is your policy for concurrent events? I know a bumper event and a color event can run simultaneously, but when filtering, can a red color event run at the same time as a green color event? Can a left bumper event run at the same time as a right bumper event? Are there any special rules for specific events?

[miniBloq]

Hi Mike!

In the original app (Root Coding), a new event canceled all the other ones. But the iRobot Coding app introduced multitasking. That is more powerful of course but comes a ta cost: the user can write contradictory commands in two events running in parallel. The only filtering we add is that if a specific event is running (horizontal line in L1), it does not triggers again until finished.

But 2 different lines of code (or 2 events) can. There, the last command arrived for the same subsystem (motors, for example), overrides the previously running one.

In the new system, you can not only have a left bumper event running in parallel with a right bumper one, but even 10 left bumper triggers can initiate 10 parallel tasks, the same as N start program events can start N tasks.

[Rebecca-iRobot]

Hi mike! Sorry for my late reply :) Wanted to thank you for your help with this! It's an amazing tool that I think students and teachers will really appreciate!