Hi Sakar,
I've read through the code, mainly the one with limited number of rules,
but I checked the unlimited version as well - but that's the same only
with linked list.
Things that I like: It's simple and it's actually quite readable. You use
simple array to store rules which is just fine. I think you don't need
linked list for that, that would be just wasting memory. I also like the
fact that you accept incoming messages with fixed size only.
Things I don't like: I don't think it's doing what you want it to do and
it needs more polishing... :)
BTW: please don't feel discouraged, I'm glad you're playing with this :)
So some thoughts:
1) use more #define. The code is full of constants for array indices.
Also, use #define DEBUG macro or similar to use debugging only when
compiled in. Unless you want some debug mode in production mode.
2) split it into more files. I think you could use a second file with code
that would parse the incoming data. Then in loop() you'd just call
something like recv_msg(), parse_msg() and act upon that.
3) rule execution should be also in its own function(s). Also, note that
even though you fail on the first condition you still check all the other
and then do nothing :)
I also found a bug:
When you receive new rule from computer, it has indexA that tells you
where you put it in the array. That's fine when you want to overwrite old
rules, but it fails when you already have, for example, 3 rules and the
new rule has index 5. In that case there will be no valid rules in
rules[3] and rules[4], but as you increase currentDeep, rules[3] will get
executed.
Anyway, to reply to your question:
So far you can't do it. Your rules are now too complex - you actually
check all values you can for each rule. But if you want a simple rule like
"go forward until there's space at least 20cm", you have to set up high
and low temperatures as well.
What you could do is to make extra structure for each single sensor. Then
join them in an union and that union put inside a structure with a char
that would tell you which one is it. Like this (for inspiration):
#define MAX_SUBRULES 16
struct temp_rule {
unsigned char temp_low;
unsigned char temp_high;
};
struct dist_rule {
unsigned char dist_low;
unsigned char dist_high;
};
typedef enum {
TEMP,
DIST,
} rule_type_t;
struct subrule {
union spec_rule {
struct temp_rule;
struct dist_rule;
}
rule_type_t type;
};
struct rule {
struct subrule s_rules[MAX_SUBRULES];
unsigned char n_subrules;
}
Now you'd need to adjust your parsing code to accept a different command:
add subrule. So, for example, from your computer you'd send command to
create rule (which would be empty, n_subrules initialized to 0, and
s_rules array empty. Then you'd send command to create subrule inside one
of the existing rules. That would add the rule into the array s_rules and
increase n_subrules by one in that rule.
I am now confident you are lost in this mess of rules and subrules. :)
Feel free to change the name.
Anyway, to finish up. All subrules inside a rule would be checked with AND
between them, and all rules with OR between them. That would give you
enough power to express XOR and NAND as well, therefore any logical
operation - but only in the "top level". If you wanted even more powerful
rule execution, you'd have to introduce brackets which, I think, would
make your code somewhat more complex.
Regards,
Dominik - eddy
On Tue, 14 May 2013 07:56:35 +0200, Sakar <[email protected]> wrote:
Hi Petr,
Sorry for the delayed response. We were just slammed and could not think
of
much besides work/code etc. Here is what we ended up with:
https://github.com/SpaceAppsKtm2013/KarkhanaRover.
Are we going to see you in Kathmandu in Oct? It will be awesome!
-S
On Wed, Apr 24, 2013 at 3:24 PM, Petr Baudis <[email protected]> wrote:
Hi Sakar!
On Wed, Apr 24, 2013 at 09:21:06AM +0800, Denisa Kera wrote:
> QUESTION: For the arduino gurus on this list. One BIG challenge that
we
> could not tackle during the 48 hours (but want to do now), is allow
for
> multisensor rules. For e.g. right now you can say "If obstacle is less
than
> 20 cm then go left, then go forward for 10 sec and stop" but we want
to
be
> able to permit chained rules e.g. "if obstacle is less than 20 cm AND
you
> are on a black surface then go left". We have a pretty good rule
execution
> engine could be modified to handle chaining... what we don't have a
good
> data structure to store multiple rules on... so if you have any ideas
of
> approaches we should explore, drop me a line - Sakar
The question is rather general - what rule representation do you use
now? I would work from that to extend it.
Petr "Pasky" Baudis
_______________________________________________
Brmlab mailing list
[email protected]
http://brmlab.cz/cgi-bin/mailman/listinfo/brmlab
