Rubensb-pfc-itis
- Project Name:
- Authors: Rubén Salamanqués Ballesteros (r [dot] salamanques [at] alumnos [dot] urjc [dot] es)
- Academic Year: 2011-2012
- Degree: Undergree
- Jde Version: jde-5.0
- SVN Repository: Repository
- Tags: jde, gazebo, C++
- Technology:
- State: Developing
- Source License: GPLv3
- Document License:
Contents |
(07/05/2012)
Complete version had been developed, now includes a tree view with the whole structure of the project, it expands and contracts following the navigation in the draw area, this is very usefull to know how exactly you are drawing.
Most of the right buttons had been supressed and now its functionality are in popup menus showed by right clicks in the items drawed in the canvas, you can now move the items just by click and drag them and navigate to deeper levels by double-click on states, to navigate upper a new button 'UP' was added. States with 'sons' are paint in green and they will be cyan in case they haven't.
You can save and open the project and when it's finished you can generate the code and compile it. As a result of that a jderobot 5.0 component will be created and you could see the results using the gazebo 0.9 simulator.
We will show some videos with all these new features soon, now you could download the application sources (at /trunk/visualHFSM in the repository) compile and use it!
(16/04/2012)
First working video!
Still having some issues, if you name a state after paint it green (green means it has a 'son' below) it turns blue again and aplication could crash if you navigate between levels after press some buttons like "Transicion" so there's still some work to make it fully functional but if you use it "well" it can generate a proper hierarchical automata code.
More options will be added in popup menus.
(10/04/2012)
A first complete version of visualHFSM is almost done, it can show and navigate between levels and the code generator create a multi-thread control for a multi-level automata, firsts test will come to ensure the correct functionality of this version, by now there is no automatic GUI for the generated component and the program's interface has no tree view for improve the navigation but the popup menu is already implemented doing the program more user friendly. We'll show a video with all this new features when all finally works propertly, hope soon.
(02/03/2012)
A new dinamic memory structure was implemented, it makes possible to save the multi-level automata data, now we can create xml files with a new distribution that allows to save the hierarchical automata.
The new memory structure is a list of "sub-automatas", each one has the same structure that the automata's from Vicoe had. Using this list is quite easy to take the most of the procedures and functions used until now.
As well the xml distribution is almost the same as before, all the data is save in a deeper level of subautomatas nodes.
<visualHFSM>
<Subautomata>
'single level automata'
<\Subautomata>
<Subautomata>
'single level automata'
<\Subautomata>
<Subautomata>
'single level automata'
<\Subautomata>
<\visualHFSM>
First version of visualHFSM
(10/02/2012)
We've got the very first version of visualHFSM, this is by now only a modified version of vicoe using "the new introrob" (developed by Maikel Gonzalez) as base code for the components generated instead of "introrob" used in vicoe. The control is ruled by the hierarchical schema showed before but only for a simple-level automata, a bumpandgo example contained on vicoe's documentation.
Changes on this part are necesaries in order to trully adapt the code generator to a multi-thread multi-level automata, thus will come when we change the xml with a new organization for containing a hierarchical structure.
(18/01/2012)
Mutex added to the state changes to ensure the correct execution of the automata. Added a popup menu on the canvas to improve the user experience, items can move by default too, options doesn't work by now, it is only a sample, here is a video to show this.
Now working on the XML part of the project, trying to understand the language and the previous version of vicoe, libXML++, etc.
(04/01/2012)
Mutex added to the ICE interfaces related variables, this change solves the problem with the basic component when it executes control and gui threads at the same time.
Working on the improvement of the 'vicoe' gui, trying to implement a more intuitive popup menu when the right-button is clicked, it will allow to edit the state code, make it initial, delete it, etc.
Hierarchical schema achieved
(22/12/2011)
A whole new schema was implemented, it changes the "do-while" previous version for a "double switch" one. In the first switch the iteration's conditions are tested and it choose the correct state to execute, the second switch choose between different state's code and execute it.
There are news on the hierarchical part too, now every control thread has de same "level", the "Main" thread only creates the other ones who make the automata works.
A "ghost" states were added to the normal states, this ghost states are used as keys for the lower level automatas, a low level automata only executes its code if its father isn't in a ghost state (and if this non-ghost state is its key of course).
The old iterationControl function has been changed too, now there are several "iterationControl" functions, one for each automata, in this way an automata only sees its proper variables.
(16/12/2011)
A first hierarchical schema is done, iterationControl now accepts a thread ID to execute diferent codes depends on the thread that call it. A "secondary Main" make the diferent thread's speeds possible. A "thread data" structure is now necessary to pass arguments to this secondary Main, it contains the thread ID and its cycle. All of these new features can be seen at the "/tags/Jerarquico-V1/control_class.cpp" file in the repository.
iterationControl(th_id){
switch (th_id){
case 1://Parent automata code
do{
//Automata as shown before
switch estados_padre{
.
.
.
}
}while(estado_cambiado_1==true);
case 2://Code of a second level automata
do{
//Automata as shown before
switch estados_hijo{
.
.
.
}
}while(estado_cambiado_2==true);
.
.
case N:
}
}
Now in the control->Main the threads are created and lauched linked to the control->miMain function that allows to control the thread cycle and call to iterationControl with the correct thread ID.
(09/12/2011)
Here's a little video of the "Follow line" automata.
Now I'm working on a functional hierarchical code based on diferents threads for each level.
(01/12/2011)
A new version of the schema was implemented, it have a "priority" variable to ensure the execution at least once of a state when the automata transites to it:
do{
switch(estado_actual){
case estado1:
/*Percepcion propia del estado para poder actuar*/
if (prioridad){
prioridad = false;
/*Código del estado*/
}else{
if (/*Condición de la transición 1*/){
estado_actual = estado2; //se cambia al estado que corresponda
estado_cambiado = true;
}
if (/*Condición de la transición 2*/){ /*si añadimos "&& !estado_cambiado"
damos prioridad a las primeras transiciones,
si no lo añadimos damos prioridad a las últimas
en caso de que varias puedan solaparse*/
estado_actual = estado3; //se cambia al estado que corresponda
estado_cambiado = true;
prioridad = true;
}
if (!estado_cambiado){ //no se ha cumplido ninguna condicion de transición
/*Código del estado*/
estado_cambiado = false;
}
}
break;
.
.
.
case estadoN:
/*Medicion del tiempo*/
if(){
}else
if(/*Tiempo transcurrido = Tiempo marcado*/){ //para los casos de transiciones temporales
estado_actual = estadoM;
estado_cambiado = true;
prioridad = true;
}
if(!estado_cambiado){
/*Código del estado*/
estado_cambiado = false;
}
}
break;
}
}while(estado_cambiado = true);
Now I show both automatas developed until now, first Bump&go and next FollowLine:
And here an image of the color filter used to follow the line. As we can see there are four horizontal lines that are taken to meassure if the line is in the right place.
In the next edit I show a video of this behavior.
(16/11/2011)
A fist automata was programmed with a simple Bump&Go behavior, it can be seen at "trunk/ChocaGira_aut/" folder in the repository, specifically the control_class.cpp file is where the automata's code is, this automata use an improved schema like this:
do{
switch(estado_actual){
case estado1:
/*Percepcion propia del estado para poder actuar*/
if (/*Condición de la transición 1*/){
estado_actual = estado2; //se cambia al estado que corresponda
estado_cambiado = true;
}
if (/*Condición de la transición 2*/){ /*si añadimos "&& !estado_cambiado"
damos prioridad a las primeras transiciones,
si no lo añadimos damos prioridad a las últimas
en caso de que varias puedan solaparse*/
estado_actual = estado3; //se cambia al estado que corresponda
estado_cambiado = true;
}
if (!estado_cambiado){ //no se ha cumplido ninguna condicion de transición
/*Código del estado*/
estado_cambiado = false;
}
break;
.
.
.
case estadoN:
/*Medicion del tiempo*/
if(/*Tiempo transcurrido = Tiempo marcado*/){ //para los casos de transiciones temporales
estado_actual = estadoM;
estado_cambiado = true;
}
if(!estado_cambiado){
/*Código del estado*/
estado_cambiado = false;
}
break;
}
}while(estado_cambiado = true);
As we can see it is mostly the same as before but I added perception in each state and break points for a correct behavior in the switch loop, I still working on a "Follow line" behavior with hierarchy, trying to implement it with several control threads.
First "simple level" schema done
(09/11/2011)
We're working now in the automata's schema, trying to find a general framework for any automata we want, here's a first approximation with no empty iterations, reactive behavior ('look & do'), several transitions in one state and temporal transitions, no hierarchy:
do{
switch(estado_actual){
case estado1:
if (/*Condición de la transición 1*/){
estado_actual = estado2; //se cambia al estado que corresponda
estado_cambiado = true;
}
if (/*Condición de la transición 2*/){ /*si añadimos "&& !estado_cambiado"
damos prioridad a las primeras transiciones,
si no lo añadimos damos prioridad a las últimas
en caso de que varias puedan solaparse*/
estado_actual = estado3; //se cambia al estado que corresponda
estado_cambiado = true;
}
if (!estado_cambiado){ //no se ha cumplido ninguna condicion de transición
/*Código del estado*/
estado_cambiado = false;
}
.
.
.
case estadoN:
if(/*Tiempo transcurrido = Tiempo marcado*/){ //para los casos de transiciones temporales
estado_actual = estadoM;
estado_cambiado = true;
}
if(!estado_cambiado){
/*Código del estado*/
estado_cambiado = false;
}
}
}while(estado_cambiado = true);
(24/09/2011)
Integration with glade achieved, visible results are similar to the last video but now the window with canvas doesn't crash the entire UI when it closes and the check-button "Mostrar canvas" works.
(20/09/2011)
This is a video showing a Gnome::Canvas with a few items and events on it (I implemented a drag&drop), it hasn't fully integration with glade yet so it doesn't work properly with the other windows but this integration is almost done and I expect to have all working together soon.
(13/09/2011)
This week I talked about visual threat distribution with Julio Vega and then I decided to implement the gnomecanvas widget in a separate unit, it doesn't work by now because of its integration with glade but it's almost done, no events on the canvas by the moment.
Firsts steps
Here's a video showing a simple Bump & Go on Gazebo 0.9, just to know how all components of jderobot works together. Little slow on capture (taked from a limited VM), it goes faster in real time.
