[Jde-dev] refactorizacion eldercare y carclassifier

David Lobato dav.lobato en gmail.com
Vie Dic 10 00:26:50 CET 2010


Hola,

Respondo por partes:

2010/12/10 redouane kachach <redo.robot en gmail.com>

> Hola David,
>
> Del EldeCare no tengo mucha idea as� que no puedo aportar mucho. Solo por
> curiosidad en los par�metros que has puesto que significan la (w,h)? Te
> refieres al bonding-box del objeto?
>
>
El �ltimo algoritmo de ElderCare hace el tracking de prismas que se definen
por el centro,largo,ancho y alto (este se me ha olvidado, lo apa�o). Es una
descripci�n de alto nivel, pero permite ver que metemos y que sacamos. Con
el algoritmo que uses en el clasificador deber�as hacer lo mismo. Empieza
por alto nivel, y si luego quieres describir alg�n otro algoritmo usado por
este hazlo a parte.



> Sobre el CarClassifier mi idea es re-escribirlo desde zero en C++
> utilizando los patrones de dise�o que propones para la arquitectura y
> tirando de OpenCV cuando haga falta. Tengo que pensar
> un poco en como quedara la cosa ya que mi idea es separarlo en dos
> componentes tracker y classifier y as� el primero podr� ser utilizado como
> componente por separado. Pero no tengo claro
> si esta separaci�n va ser sencilla y en su caso el impacto que tendr� en el
> tiempo de ejecuci�n total. Teniendo en cuenta que en este caso como en el
> CarSpeed las cosas tienen que correr en
> tiempo-real as� que habr� que aplicar todas las optimizaciones posibles,
>
>
Me parece buena la idea de separarlo, ser� m�s f�cil de probar luego y sobre
todo lo podremos reutilizar. En cuanto a la unidad funcional no la basar�a
en componentes, si no en librer�as (aunque luego hagas un componente si
quieres...). De esta manera tendremos software mas manejable y reutilizable.
Adem�s es cierto lo que dices, necesitamos tiempo real o lo m�s parecido que
podamos y la comunicaci�n via componentes nos va a limitar. Lo mejor ser�
meterlo todo en el mismo componente con llamadas locales de las de toda la
vida.

Importante que uses OpenCV y STL para todo lo que puedas. Tambi�n te invito
a que eches un ojo a los punteros inteligentes incluidos en el TR1 de C++
(#include <tr1/memory> y std::tr1::shared_ptr) pueden ser �tiles para
manejar memoria m�s efectivamente.

 Te propongo que analices los algoritmos que quieres refactorizar y plantees
un API basado en el patr�n de dise�o que coment�bamos y lo repasamos juntos.

Un saludete,
David.



> Saludos,
> Redo.
>
> 2010/12/1 David Lobato <dav.lobato en gmail.com>
>
>> Hola,
>>
>> El an�lisis de alto nivel del algoritmo Eldercare ser�a el siguiente:
>>
>> https://jde.gsyc.es/index.php/Eldercare_Algorithm
>>
>> S�lo he tenido en cuenta las entradas y las salidas. Queda refinar el
>> apartado de par�metro de configuraci�n.
>>
>> A partir de esto, podemos generar el API de alto nivel para usar el
>> algoritmo.
>>
>> �Comentarios?
>>
>> 2010/11/30 David Lobato <dav.lobato en gmail.com>
>>
>> Hola,
>>>
>>> Este mensaje va dirigido a los que est�is liados o vais a estarlo en
>>> breve con Eldercare y Carclassifier, aunque si alguien quiere a�adir o
>>> comentar algo ser� bienvenido.
>>>
>>> Creo que el primer paso que debemos dar antes de a�adir nueva
>>> funcionalidad a lo que ya existe es refactorizar los algoritmos de modo que
>>> los empaquetemos en sendas librer�as que nos faciliten su uso/mantenimiento
>>> posteriormente.
>>>
>>> El estado actual de Eldercare (y supongo que tambi�n del classifier) es
>>> un conjunto de funciones, alguna clase y muchas variables globales, que
>>> hacen un poco complicado ver que est� sucediendo y mucho m�s depurar los
>>> errores. Adem�s de estar bastante cohesionado con la interfaz gr�fica.
>>>
>>> La idea es sacar toda la funcionalidad del algoritmo y encapsularla,
>>> definiendo un API para su uso. En mi TFM [1] describ�a un patr�n de dise�o
>>> para algoritmos iterativos (derivado de patr�n Strategy) que creo encaja en
>>> la mayor�a de algoritmos que hacemos, y sin duda encaja en el de eldercare y
>>> carclassifier. As� que creo que puede ser un punto de partida para ir
>>> definiendo las clases que tendr� cada algoritmo.
>>>
>>> El m�todo de trabajo para refactorizar un algoritmo de los que tenemos
>>> hasta la fecha es simple:
>>>
>>>    1. Analizar sus entradas, salidas y par�metros de configuraci�n
>>>    2. Declarar las clases en funci�n de lo encontrado anteriormente (.h)
>>>    3. Definir las clases usando el c�digo que ya tenemos (.cpp)
>>>
>>> Los puntos 1 y 2 podemos ir trat�ndolos en com�n para llegar a una
>>> soluci�n consensuada. Si os parece empiezo con el punto 1 de Eldercare y
>>> continuamos juntos.
>>>
>>> Comentarios??
>>>
>>> Un saludo,
>>> David.
>>>
>>>
>>> [1]
>>> http://svn.jderobot.org/users/dlobato/tfm/trunk/memoria/jderobot5_thesis.pdf
>>>
>>> --
>>> David Lobato Bravo
>>>
>>> Universidad Rey Juan Carlos
>>> c/Tulipan s/n
>>> 28933 M�stoles
>>> Madrid, Spain
>>> http://jderobot.org
>>> http://es.linkedin.com/in/davidlobato
>>>
>>>
>>
>>
>> --
>> David Lobato Bravo
>>
>> Universidad Rey Juan Carlos
>> c/Tulipan s/n
>> 28933 M�stoles
>> Madrid, Spain
>> http://jderobot.org
>> http://es.linkedin.com/in/davidlobato
>>
>>
>> _______________________________________________
>> Jde-developers mailing list
>> Jde-developers en gsyc.es
>> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
>>
>>
>


-- 
David Lobato Bravo

Universidad Rey Juan Carlos
c/Tulipan s/n
28933 M�stoles
Madrid, Spain
http://jderobot.org
http://es.linkedin.com/in/davidlobato
------------ pr�xima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20101210/9807b271/attachment-0001.htm 


More information about the Jde-developers mailing list