Hi, <br> The two key challenges, in my opinion, for an embedded version of the framework as it is in its current state of development is the reliance of Windows Threading API's for in process threading, and the 10+ network ports needed for inter-process communication (which is primarily due to the use of the Galaxy Communicator). There is work in progress by myself to make the Olympus architecture build on Unix based Operating Systems, but there is no work to replace the Galaxy Communicator with a version that uses Kernel level inter-process communication nor is there an effort to create a single executable version of Olympus to the best of my knowledge. We would accept contributions addressing both of the key challenges. (E-mail me personally with your preferred user name and password for filing bugs and committing, and I will get you setup to submit patches (that someone will checkin after review) through "bug" reports on <a href="http://trac.speech.cs.cmu.edu/olympus" target="_blank">http://trac.speech.cs.cmu.edu/olympus</a> , and I will find out the policy about if and when to give commit access if possible.) In general, as mentioned earlier, our text to speech synthesizer library and our speech decoder library are both optimized for embedded systems already, but the rest of the system is not; however, while we primarily run the system on powerful machines, the system is usable and responsive on our less powerful development machines (which usually have around a 2 GHz P4 and 1 GB RAM). Both the replacement of the Window's Threading API's (especially if the embedded device will not run Windows Mobile/CE) and the Galaxy Communicator would significantly help the system work well in an embedded domain. I will be sending out an e-mail shortly about a meeting to discuss progress on the Unix conversion, and you could join remotely if you can. <br>
Of course, from the prospective of the system in general RavenClaw, Apollo etc. both contain code for states that are rarely used and could probably also be replaced with something more light-weight or have some states/code not compiled. I also understand that language processing is heavily reliant on preprocessor variables and logic written for the specific processing in C, and that could be probably be improved as well. <br>
I will talk to other developers tomorrow and get their opinions as well.<br><br>Thanks,<br>Benjamin Frisch<br>Undergraduate Research Assitant<br>
<br><div class="gmail_quote">On Thu, Jan 15, 2009 at 7:35 AM, Chandrakanth Reddy Dargula <span dir="ltr"><<a href="mailto:Chandrakanth.Dargula@infotech-enterprises.com" target="_blank">Chandrakanth.Dargula@infotech-enterprises.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi,<br>
I am software engineer in embedded domain<br>
and interested in contributing to the open source olympus dialog<br>
management framework. I am a rookie to this framework. Could you<br>
please let me know what are the key challenges still present in this<br>
framework and which are i can concentrate to contribute to this<br>
framework.<br>
Could please also let me is there any research or development going on<br>
to develop similar kind of framework for handheld devices(embedded<br>
applications). If it is already started what are key challenges which<br>
still needs to be addressed for the same.<br>
<div><br>
Regards,<br>
Chandrakanth.<br>
________________________________________<br>
From: Antoine Raux [<a href="mailto:antoine.raux@polytechnique.org" target="_blank">antoine.raux@polytechnique.org</a>]<br>
</div>Sent: Tuesday, January 13, 2009 12:22 AM<br>
To: Thomas Harris<br>
Cc: Chandrakanth Reddy Dargula; <a href="mailto:olympus-developers@cs.cmu.edu" target="_blank">olympus-developers@cs.cmu.edu</a><br>
Subject: Re: [Olympus developers 81]: Re: memory footprint of ravenclaw framework<br>
<div><div></div><div><br>
Yes, PocketSphinx and Flite are both designed to work on handheld<br>
devices (hence the "Pocket" in PocketSphinx and the "lite" in Flite).<br>
<br>
Now this is not the case for the rest of Olympus (parser, dialog<br>
manager, natural language generation, and last but not least, Galaxy<br>
Hub).<br>
<br>
My guess is that you'd have to find (or create) a lightweight<br>
alternative to Galaxy (to let your modules talk to each other), and at<br>
least a new version of RavenClaw, which is really not optimized for<br>
performance (or memory usage). Now depending on your application, you<br>
might not need all the bells and whistles of RavenClaw (and god knows<br>
there are quite a few), so if you can get away with a much simpler<br>
dialog manager (in which case, NLU and NLG should not be a problem<br>
either), I assume you'd be able to fit a whole system on a (reasonably<br>
powerful) handheld device.<br>
<br>
antoine<br>
<br>
<br>
On Mon, 2009-01-12 at 09:08 -0500, Thomas Harris wrote:<br>
> Fortunately, PocketSphinx and Flight both have integer-only modes, so<br>
> you can manage without a floating-point unit if you need to.<br>
><br>
> -Thomas<br>
><br>
> On Mon, Jan 12, 2009 at 1:57 AM, Chandrakanth Reddy Dargula<br>
> <<a href="mailto:Chandrakanth.Dargula@infotech-enterprises.com" target="_blank">Chandrakanth.Dargula@infotech-enterprises.com</a>> wrote:<br>
> Antoine,<br>
><br>
> Thanks for your inputs. Could any one let me know what are key<br>
> challenges that will come across to develop similar kind of<br>
> system in handheld devices.<br>
><br>
> Regards,<br>
> Chandrakanth.<br>
> ________________________________________<br>
><br>
> From: Antoine Raux [<a href="mailto:antoine.raux@polytechnique.org" target="_blank">antoine.raux@polytechnique.org</a>]<br>
> Sent: Saturday, January 10, 2009 6:25 AM<br>
> To: Chandrakanth Reddy Dargula<br>
> Cc: <a href="mailto:olympus-developers@cs.cmu.edu" target="_blank">olympus-developers@cs.cmu.edu</a><br>
> Subject: Re: [Olympus developers 76]: memory footprint of<br>
> ravenclaw framework<br>
><br>
><br>
> Hi Chandrakanth,<br>
><br>
> Thank you for your interest in Olympus. I'm not exactly sure<br>
> of the<br>
> memory footprint of Olympus applications (I'm no longer at CMU<br>
> and do<br>
> not have an Olympus set up at hand to check) but I know that<br>
> we are<br>
> running the full Let's Go system (including speech<br>
> recognition,<br>
> synthesis, interaction and dialog management, etc) on a single<br>
> PC (3GHz<br>
> dual-core with 4GB of memory, although slightly less powerful<br>
> configurations would probably work too).<br>
><br>
> Hope this helps a bit... If anyone else cares to share their<br>
> own<br>
> experience...<br>
><br>
> antoine<br>
><br>
><br>
> On Fri, 2009-01-09 at 18:08 +0530, Chandrakanth Reddy Dargula<br>
> wrote:<br>
> > Hi,<br>
> > Could you please let me know approximate memory foot print<br>
> of any<br>
> > application developed using this olympus/ravenclaw dialog<br>
> framework.<br>
> > Speed requirement of any processor required to run<br>
> application built<br>
> > based on this framework.<br>
> ><br>
> > Thanking you.<br>
> ><br>
> > Regards,<br>
> > Chandrakanth.<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ______________________________________________________________________<br>
> > DISCLAIMER:<br>
> ><br>
> > This email may contain confidential information and is<br>
> intended only<br>
> > for the use of the specific individual(s) to which it is<br>
> addressed. If<br>
> > you are not the intended recipient of this email, you are<br>
> hereby<br>
> > notified that any unauthorized use, dissemination or copying<br>
> of this<br>
> > email or the information contained in it or attached to it<br>
> is strictly<br>
> > prohibited. If you received this message in error, please<br>
> immediately<br>
> > notify the sender at Infotech or<br>
> <a href="mailto:Mail.Admin@infotech-enterprises.com" target="_blank">Mail.Admin@infotech-enterprises.com</a><br>
> > and delete the original message.<br>
><br>
><br>
><br>
</div></div></blockquote></div><br>