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 sakarp@gmail.com 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 pasky@ucw.cz 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