New to WebbotLib/Axon/SoR, a few questions on the internals of Webbotlib

[GrooveHolmes]

Hi folks, thanks in advance for the help.

I just got my AxonII on Friday and this is my first foray into working with microcontrollers.  I understand simple electronics and can code fairly competently in C# and java, but am just beginning to muddle my way into C.

My problem is transitioning my brain from object orientated programming on PCs to non-object oriented programming on embedded platforms.

This might just be a C thing (learning as I go with the Axon, so I'm as new to C), but why does the appControl() method (which I read emulates/replaces the main() method) end and then get recursively called in the specific microseconds, as opposed to the (traditional main()) method being called once and continuously looping through it's own logic until instructed to end (user closes application/turns off robot).

I understand the intention and purpose behind the appInitHardware() and appInitSoftware methods, but am just trying to understand the benefit and reasoning behind having the appControl() method execute and end infinity as opposed to being ran once like the traditional main (which I read is still there, but buried in the webbotlib header files (and responsible for calling the 3 main webbotlib methods (appInitHardware/Software and appControl).

So what I'm wondering is... (keeping in mind this is day 3 into the MCU/webbotlib world):
- Why do we recursively use the appControl() method instead of the traditional main()?
- Is the appControl() method intented to contain higher level logic, or just device command logic? If the latter, where should the higher level logic code go?
     - Is the appControl() method meant to execute as quickly as possible, or take however long its supposed to take (like the main() method)?
- What is the TICK_COUNT object and how/why do I use it?
- What happens to events while the appControl() method is waiting to execute again? eg; If the appControl() method is set to execute every 1 second, and an event (user presses onboard button) occurs that is shorter then the cycle time, does it miss the event? (I'm guessing this would be handled by some kind of listening event, but if that's placed inside the appControl() method it not be listening during the wait time before the appControl() method is executed again!)


Thanks again for the help! 

(just to note, I have tried painfully over the last few days to go through all the webbotlib source c/h files to try and understand better, but due to my inexperience with C, the webbotlib API, and MCU's in general it is all very overwhelming.)

[Webbot]

I just got my AxonII on Friday and this is my first foray into working with microcontrollers.  I understand simple electronics and can code fairly competently in C# and java, but am just beginning to muddle my way into C.
My problem is transitioning my brain from object orientated programming on PCs to non-object oriented programming on embedded platforms.

Am a java/OO believer - so I understandyour pain!

This might just be a C thing (learning as I go with the Axon, so I'm as new to C), but why does the appControl() method (which I read emulates/replaces the main() method) end and then get recursively called in the specific microseconds, as opposed to the (traditional main()) method being called once and continuously looping through it's own logic until instructed to end (user closes application/turns off robot).

appControl is not called 'recursively' - it is called 'iteratively'. ie call do { 'appControl', 'wait' )until(forever)
The advantage of releasing control back to the real main is that every time your appControl is called is that it has current loop and time info passed in. Equally the pause returned by your appControl can be used by the lib to do some 'housekeeping'.

So your appControl should execute as quickly as possible (ie no delays within it). Alternatively you can leave your main loop empty and put it all instead in a 'scheduler event' if you want it to be called every 'n' ms instead.

- Is the appControl() method intented to contain higher level logic, or just device command logic? If the latter, where should the higher level logic code go?
     - Is the appControl() method meant to execute as quickly as possible, or take however long its supposed to take (like the main() method)?

Its just like your 'old fashioned main' with an 'optional' delay specified by the return value

- What is the TICK_COUNT object and how/why do I use it?

As described in the manual a TICK_COUNT is a number in microseconds (ie 1 / 1,000,000 th of a second)

So what I'm wondering is... (keeping in mind this is day 3 into the MCU/webbotlib world):
- What happens to events while the appControl() method is waiting to execute again? eg; If the appControl() method is set to execute every 1 second, and an event (user presses onboard button) occurs that is shorter then the cycle time, does it miss the event? (I'm guessing this would be handled by some kind of listening event, but if that's placed inside the appControl() method it not be listening during the wait time before the appControl() method is executed again!)

Welcome to the world of interrupts. Once you've set up a service handler then it will be called whenever it happens regardless of whether its during your appControl etc etc

(just to note, I have tried painfully over the last few days to go through all the webbotlib source c/h files to try and understand better, but due to my inexperience with C, the webbotlib API, and MCU's in general it is all very overwhelming.)

Yep - its a whole new world !

[GrooveHolmes]

Thank you for the reply Webbot, although I'm still a bit confused!  :p For some reason, I can't help but to think of the 'iteration' of the appControl method cycles similar to the Frames Per Second on PC programming; a cyclic process that runs out of, but separate from the main() block of logic for synchronization purposes.

I'll try to flip this into bot terms (for my benefit!) using some existing well known 'bots' as an example:

The photovore bot uses, what is essentially, event driven logic to interpret and react to specific input and output (to motors). So having the appControl execute X times a second makes sense to me. Every time it executes, it reads sensors, adjusts motors. The faster the better (which oscillation compensation of course). A software emulation of a hardware circuit. (I remember building a photovore bot via tutorial with only hardware when I was learning electronics )

But what happens when you introduce higher logic, such as path memory or mapping? If we want the appControl method to execute as fast as possible, reading sensors, adjusting motors, where do I put higher level code that (in my brain) should run continually in the background (eg; the array that stores the map data, and the method that maps a safe route), or methods and functions that only need to be called less often (e.g. polling the GPS sensor).

My handicap is definitely that I 'think' from a PC world (trying to break the habit; steep learning curve!). In that regard, we just use some event listeners/handlers with some timer objects tied into some methods and functions; program executes once and only ends when told to do so. I can't help but to view my 'bot' in a similar way; the main() loads on 'boot' calls the initHardware/Software but then... *insert brain cramp here*

What I'm interpreting (and I know I'm wrong) is that my 'program' will run and end X times per second. And the implications and limitations of that concept is obvious! Everything it learned in that iteration, will be lost when the variables go out of scope at the method end. Plus, what happens when a timer delay is triggered inside of the appControl method (eg. waiting for a reply via blutooth; timing out after 10 seconds of no reply), does the method halt until the timer has lapsed?!

Again, thanks for the help!

[GrooveHolmes]

I had a long talk with a friend last night about this; I think I understand now.  It is very similar to graphical game programming and how FPS are delivered with consistency (usually called in an iterative method similar to the appControl method).

This is a method/function overtime concept (not simple to comprehend in full at first), and perhaps worthy of a mention in the docs for the new people!

[Webbot]

You may be over-intellectualizing things in some cases.

eg if appControl returns 0 then the whole 'main' is simplified to:-

do{
  appControl
} while(1);

ie in this case its just like a standard "main" loop

[GrooveHolmes]

Yeah... I was over complicating it. Much appreciation for the time and help!

[Cristi_Neagu]

Well, then, what does the number returned by appcontrol mean? I thought it was a delay that said "reapeat appcontrol after this many ms". If so, then what number should i put in so appcontrol repeats as fast as possible?

Thanks.

[Webbot]

When appControl exits it returns a delay. The lib then pauses for the 'returned delay' - 'how long it took to run appControl'.

So assuming appControl takes around 5ms.
Then if you return delay=0. Then it waits an extra "0 - 5" ie -0.5ms which is negative so it doesn't wait at all.
If you return a delay of 7ms then it waits an extra "7 - 5" ie 2ms. So the next appControl will be called 7ms after the previous one.

Therefore: if you just want appControl to run as fast as possible then just return 0.

[Cristi_Neagu]

Oh...i see... Interesting design ideea...

Thanks for the reply

[kl22]

Hi,
Well i'm new to this too... Not sure why you would do this but you could, theoretically, not let app control end and keep doing what you need to do inside the first call of appControl. So it pretty much acts as the main() in a standard c program.

For example (short pseudo):

appcontrol() { //acting as main()
  while (not maze goal reached)
    //do heuristics
    //map navigation
    //and so on
    //
  }

  return 0; //no real point as everything happens in the first call, so you might want to induce an infinite loop before so that the appControl doesn't get called again
}

the way appControl was meant to be used:

appControl{
  if (not maze not complete){
    //do AI (heuristic calcs, movement, etc
 }
 return 0; //or any other delay so that AI can be redone
}

Both essentially do the same thing... but webbot's implementation makes the coding cleaner in my perspective.

the way i see it, the reason why webbot decided do with an infinitly looping appControl is that majority if not all robot AI has some form of infinite loop as AI needs to be actions and goals repeatedly needs to be updated and performed.

correct me if i'm wrong.

[Webbot]

appcontrol() { //acting as main()
  while (not maze goal reached)
    //do heuristics
    //map navigation
    //and so on
    //
  }

  return 0; //no real point as everything happens in the first call, so you might want to induce an infinite loop before so that the appControl doesn't get called again
}

The above will, of course, function correctly but I don't recommend you do it as it makes the 'assumption' that 'appControl' is the only thing that ever gets called from within the real main loop. Whilst this is true, for now, it doesn't necessarily mean that it will always be true in the future.

For example: I could change the main so that whilst it is idling away for the returned 'duration' it could call a function like 'appIdle' - which could, say, flush changed data from RAM to EEPROM.  Not saying that I will make that change - its just an example.

So for future compatibility you should make the appControl function return after each 'pass'.

[richiereynolds]

From my point of view I don't see webbotlib as just just a library, it's also a framework for running your code.
It's not terrifically flexible but it is terrifically useful.

If you want to get the most benefit from it I think you're best to stick to the usual ways of using it as is shown in the examples in the documentation, well, as much as you reasonably can to accomplish your task.