Hi all,

I'm new to RobotC and have picked it up from the samples given in the package. However, I cannot seem to grasp how to code for an event.

The example given seems to point to the code below, but while this compiles, it doesn't have the desired result: beeping when the touch sensor is pressed doesn't happen.

Can someone please point out where I have gone wrong?



Any help appreciated!

Cheers, Jase250.

Hangover from other languages...

hehe: void main, what was I thinking.

Hmm... hungover or not, I obviously still don't grasp it...

task main,
I'd suggest...
(but don't know, if that's the reason why it doesn't work with the listeners... )

Hi

You need to add the following line before the SetEvents:
SensorType[S2] = sensorTouch;

I would also suggest you run this as a separate task rather than in main and add a wait1Sec(1) into the monitor part.
thus:


It then seems to work fine.

hmmmh...
I thought the sensor watchers induce background tasks by themselves - otherwise you won't need them, so why put them into an endless task?
(Or could this be another bug?)
Otherwise you just could pack your sensor value query and assignment into your extra task and forget about all the sensor watchers (that's the way I'm doing... )

(sorry for my English )

Hi

Quite right, you don't need another task
This would be better

I wonder if the monitor-while-loop is really needed.
There are similar constructs in LeJos and NQC, and there you use it in a different way:
- you once start the Sensor listener, maybe at the program start; this causes a hidden endless task;
- you ask anywhere in any subroutine or different task, if there has happend a sensor event, e.g., in this case maybe in a while loop...;
- you react to the event if there was one, otherwise do sth else("try...catch...")

or am I completely wrong?
BTW: isn't there any a code example source ?

Actually you don't need the while loop inside the monitor block, at least not for this simple example.



There is a sample program called 'NXT Event Sample.c'

my fault: I misunderstood "monitor", I thought it was for starting the monitoring thread, not for "if no event", and I was used to "catch" for the exception, not for "if event", now this seems to me kind of other way around...

so:
setEvent once,
monitor...catch inside the loop (like: if no event ...else if event)

so there were just 2 mistakes in the code posted by jase250 at the top :
"task main" instead of "void main", and
"SensorType[S2] = sensorTouch" missing

right? does it work now?

Thanks for your contributions, people. True, in attempting to figure out the events I neglected to assign the sensor.

So let me see if I have this straight, because the event monitoring seems a little pointless in the way I understand it now. It seems that if you want to be monitoring an event, then the main body of your program must either be inside the code for this, or be a routine called from here.

This is what I mean:

It makes more sense to me to be able to initialise the monitoring code, then just leave it alone until the event triggers, as such:


I must be missing the point, but would appreciate having it shown to me. I can only assume that it must be started in a separate task, but as Ford stated, why have another task to look after a task...?

If this is the way to use an event, surely this code is simpler and just as effective (sonar mounted on motor - monitors for it being knocked by an object the sonar missed, eg sound absorbant material):


Thoughts?

hi,
I doubt if it's possible to leave both the listener initialization and the event checking outside any loop.
As I understand this issue, the initialization indeed has to be started once.
But anywhere there has to be made a decision what to do, either if this event has happened ("behavior 1)", or not ("behavior 2"). This could happen in your motor steering routine. Sure, if you want to react only once in your program at all, there doesn't have to be a loop, but if you want to do this maybe several times or each time during run time, this
monitor...catch switch
surely will have to be queried in a loop.

If the "event-behavior" is additional to the standard behavior, you may do it by an extra task. In case of an event then both behaviors are running simultaneously.
And if there isn't anything to do in case of no event (no behavior 1), you may let the program or task wait until there will be one.

Otherwise, if you have 2 "excluding" behaviors and you want to put them into 2 different routines, you will have to program a sort of "behavior handling". I myself did this before using a subsumtion (subsumption) architecture. By this one the "higher level task" is idle if no event happens, so the lower task got the control; if the event happens, the other, higher level tasks takes the control and the lower one becomes inactive - I can't imagine how to do it by an other way...

But, to be honest: I think that the event listeners are made for people who wish to avoid to write their own multi tasking programs. If you want to handle sensor events in different tasks, I'll suggest to write the sensor checking routines by your own.

(sorry for my English, I might have explained this in a better way in my native language)

Hi again,

Yes, I think we are on the same path. I don't know the fancy terminology, but I have a hiearchy of 'modes' which the robot steps through, depending on the result of an attempt to complete the previous task. I think this is similar to your subsumption architecture.

Of course, I do want my sensors to be monitored continuously, but I want this to happen in the main part of my program, not in the 'monitor' or 'catch' bit of the event code.

Thanks for your input. I will be ditching events and stick to monitoring the sensors through my own tasks.

Cheers, Jase.