FreeRTOS 6.1.0 with Axon Source 1.11 port

[thesa1nt01]

To all,

I have sucessfully ported (with the help of the FreeRTOS forum, my robot team, and my professor) FreeRTOS 6.1.0 to the Axon and integrated it with the Axon 1.11 source code.

Admin/Webbot, I would like to release it back to the community.
Are there any constraints you would impose?

Timer 1 is being used by FreeRTOS.

Regards,

[Webbot]

The Axon library available on this site was done by Admin - so its his permission you need.

Whereas I own WebbotLib available at http://webbot.org.uk

[thesa1nt01]

I see. I just figured the two of you were affiliated.
Have you considered integrating your libraries into a real time operating system?

[Webbot]

Have you considered integrating your libraries into a real time operating system?

Never really had any serious inquiries about doing it - although I'd probably use FemtoOS as it has a very small footprint.
My hunch is that it would require a reasonable amount of re-factoring to achieve - effectively giving me two versions of the library - which is a pain as I then have to add new features twice.

[thesa1nt01]

While this is true (in reference to size), FemtoOS does not have as much support as FreeRTOS, which is why we went with it.

Redoing work is a pain; especially if it doesn't work the second time.
You do have a great library, but some sort of hard real time tasking would be nice.

[Admin]

I ditched my own Axon v1.11 for WebbotLib ages ago

Anyway, what can this OS do that WebbotLib can't that you need? Maybe you can convince Webbot to add these features to WebbotLib.

[thesa1nt01]

Hard real time multitasking.
Webbotlib cannot do multitasking.
His previous reply explains why he doesn't want to implement that.

Is there a way I could contribute my port?

[Admin]

Just out of curiosity, what are you doing on the Axon that requires hard realtime multi-tasking? (serious question)

[thesa1nt01]

(just to clear up a point, we're building a robot [no sarcasm intended])\

We're pursuing an implementation called hybrid architecture, where we have one microcontroller running tasks that have been vertically decomposed (subsumption architecture / behavioral layering), and the other microcontroller (actually a beagleboard in this case running ROS) having tasks horizontally decomposed.

The Axon acts like the reptilian brain, keeping the robot safe and interfacing directly with actuators and most sensors, while the Beagleboard does all the non-real time computationally intensive tasks and communicates solutions (in the form of navigation instructions) to the Axon as it comes up with them.

The non-real time system does all the heavy mapping and localization, and the real-time system makes sure the robot doesn't run into walls and things like that.

I could go on, but I think that's a lot for now (maybe).

I'm the same guy that made the big quadruped on your examples page.

Regards,

[Admin]

hmmmm I still don't understand why you need a hard real-time multi-tasking OS . . .

I mean, just a few quick loops and some basic hardware/software interrupts on the Axon should be fine . . .

[thesa1nt01]

But the things we're doing aren't quick things.
We're filtering accelerometer data, pid, and basic localization.

We'd already tried something close to that before and made the decision to convert to multitasking.

Besides, using interrupts alone doesn't fit into the subsumption/vert decomp schema.

[Webbot]

Well you can get some sort of multi-threading by using the scheduler in WebbotLib. This includes being able to place your 'main' into the scheduler.
Others have used this to drive Kalman filters at regular timed intervals with success.

But to be honest... I see the complexities of multi threading as being way too much for the average robot enthusiast. IMHO they struggle with 2 tasks (foreground and interrupt) and the use of 'volatile'. So in a multi thread environment there are all sorts of other complexities: mutex/semaphore as well as an understanding of pre-emptive task switching  etc which will make WebbotLib into an 'advanced user only' environment whereas its trying to be 'easy for all'. eg There are times when you are trying to measure exact incoming pulse widths (eg Sonars) and a task switcher can get in the way - meaning extra code to stop the task switching happening.

The code in any multi-threaded systems is uglier and bigger as a result of the complexity.

Not trying to dismiss RTOS - but WebbotLib is aimed at the novice upwards whereas RTOS is probably aimed at advanced upwards. It certainly makes debugging complex!

[thesa1nt01]

While it is true that you could run a complicated thing that way we are going to be running multiple complicated things and we experienced problems with a simple ir scanning and reaction program. As we have multiple tasks written by multiple programmers, we reasoned it would be simpler to multitask, so that each task wouldn't have to cooperate with the other, other than when they needed to communicate with each other (which isn't really cooperation in the same sense).
This independence, we felt, gave us greater freedom.

As far as making webbotlib an 'advanced user only' system, I disagree. while the RTOS code would make the uploaded hex file bigger, the scheduler doesn't start unless you call vTaskSchedulerStart. If you just write code normally without ever calling the scheduler (and not use anything related to timer1), the code would run like everyone is used to. Alternatively, the code could be wrapped in a single task, and as long as the FreeRTOS API functions aren't used, again things would run as before (other than the brief tick interrupt).

Lastly, time sensitive or resource shared operations in RTOS need only be wrapped in two short functions or macros.

I'm not trying to shift your paradigm, but you wrote a great library and a real time OS, I'm sure would only complement it.

Regards,

[Webbot]

One thought springs to mind - if I can ever find the time to do it - is to have a dummy object in Project Designer called RTOS. This object then changes the generated code to include any RTOS headers and libraries as well as mark Time 1 as 'used'. But this would depend on what else I might need to change in the library core.

It will DEFINITELY have to be an optional component - largely because it uses Timer 1 as this is the only 16 bit timer on devices like the ATMega168/328 etc and if this is being hogged by an unused RTOS then the resulting 8 bit timers will severely restrict what the users can add to their own projects.

Bear in mind that I have some users asking for more power/options in WebbotLib at whatever the cost (ie 64k+ mcus are cheap) but I've also got others wanting it to work with ATtiny/ATmega8 processors. Can't please all the people all of the time!!! This last requirement is really driven by the $50 robot tutorial. ie beginners on a tight budget build it with an ATmega8 and then want to use something like WebbotLib. My life would certainly be easier if Admins $50 tutorial was changed to insist that they use an ATmega328P. Hint.

So I understand what you are saying - but I need to find the time to work out how best to support RTOS, and others, whilst still allowing the 'none' option. And that requires lots of time - which is also in demand for adding support for new sensors and mcus.

[Admin]

My life would certainly be easier if Admins $50 tutorial was changed to insist that they use an ATmega328P. Hint.

This page shows how to upgrade to a 328P for the $50 robot:
http://www.societyofrobots.com/step_by_step_atmega168_swapout.shtml

No need to hold WebbotLib back because of the ATmega8

[thesa1nt01]

Doing it through Project Designer sounds like a really good idea. Seems to give you the best set of options.

In the mean time Admin, do you mind if I post our code on our website via github?

[Admin]

As long as all proper citations are in the code, no problem here.