Closed okanasik closed 5 years ago
I cannot reproduce this issue, I checked while importing prius_crossing.xml in a new developing behavior. The transition ids were updated properly.
To reproduce the error create one behaviors having the following xml file:
<?xml version="1.0" ?>
<VisualStates>
<global_namespace>
<functions></functions>
<variables></variables>
</global_namespace>
<libraries/>
<state id="0" initial="True">
<posx>0</posx>
<posy>0</posy>
<name>root</name>
<code></code>
<timestep>100</timestep>
<namespace>
<functions></functions>
<variables></variables>
</namespace>
<state id="1" initial="True">
<posx>791.0</posx>
<posy>804.0</posy>
<name>state1</name>
<code></code>
<timestep>100</timestep>
<namespace>
<functions></functions>
<variables></variables>
</namespace>
<transition id="1">
<type>0</type>
<time>1001</time>
<posx>999.5</posx>
<posy>827.5</posy>
<name>transition 1</name>
<originid>1</originid>
<destinationid>2</destinationid>
<code></code>
</transition>
</state>
<state id="2" initial="False">
<posx>1055.0</posx>
<posy>964.0</posy>
<name>state2</name>
<code></code>
<timestep>100</timestep>
<namespace>
<functions></functions>
<variables></variables>
</namespace>
<transition id="2">
<type>0</type>
<time>1002</time>
<posx>873.5</posx>
<posy>945.5</posy>
<name>transition 2</name>
<originid>2</originid>
<destinationid>1</destinationid>
<code></code>
</transition>
</state>
</state>
</VisualStates>
Another behavior having the following behavior:
<?xml version="1.0" ?>
<VisualStates>
<global_namespace>
<functions></functions>
<variables></variables>
</global_namespace>
<libraries/>
<state id="0" initial="True">
<posx>0</posx>
<posy>0</posy>
<name>root</name>
<code></code>
<timestep>100</timestep>
<namespace>
<functions></functions>
<variables></variables>
</namespace>
<state id="1" initial="True">
<posx>791.0</posx>
<posy>804.0</posy>
<name>state1</name>
<code></code>
<timestep>100</timestep>
<namespace>
<functions></functions>
<variables></variables>
</namespace>
<transition id="1">
<type>0</type>
<time>2001</time>
<posx>999.5</posx>
<posy>827.5</posy>
<name>transition 1</name>
<originid>1</originid>
<destinationid>2</destinationid>
<code></code>
</transition>
</state>
<state id="2" initial="False">
<posx>1055.0</posx>
<posy>964.0</posy>
<name>state2</name>
<code></code>
<timestep>100</timestep>
<namespace>
<functions></functions>
<variables></variables>
</namespace>
<transition id="2">
<type>0</type>
<time>2002</time>
<posx>873.5</posx>
<posy>945.5</posy>
<name>transition 2</name>
<originid>2</originid>
<destinationid>1</destinationid>
<code></code>
</transition>
</state>
</state>
</VisualStates>
Note that these two behaviors are similar with the only difference on their transition time. The first one has 1001 and 1002 and the second one has 2001 and 2002 as their transition time and note that their transition id is same 1 and 2.
Create a new behavior using visualstates similar to the ones above; two states, two transitions. For each state of the behavior import each behavior as created with above xml files. When you save a generate a python code. You will see that only the last transition codes are generated since the last behavior transition id is same as that of imported ones.
I was looking at importmanager.py
and there is a function called updateIDs
which just calls upon updateStateIDs
. Why is updateIDs required?
Also I would like to add code to update transition ids.
Hi @sudo-panda , VisualStates supports functionality to import pre-developed automata into a new developing automata using the Import feature. Take an example of autonomous prius car, in which the car needs to avoid any obstacle coming in front. Hence user need not develop the obstacle-avoidance behavior again, can import directly from kobuki-obstacle-avoidance example. thus, in general, we can have a library of different prebuilt automatas through which the user can import an existing behavior and build his solution upon it. Hence a prebuild behavior would have old ids which need to be updated while importing according to the new developing automata. Also, we are currently documenting the same of which you can review here - https://github.com/jderobot/VisualStates-examples/wiki
I think there was a confusion. I know that there is an import function. I was not sure why the updateIDs function was required. I have added functionality to it so it's no longer an issue.
Also, if it wasn't clear, I should declare that I am participating in GSoC with JdeRobot as my Organization. The project I am pursuing is "A parameterized automata Library for VisualStates tool".
Sure. Thanks for the PR. I'll review it soon.
Referencing it here - https://github.com/JdeRobot/VisualStates/pull/98
When a behavior is imported in another behavior, we need to update the ids of transitions. In the current implementation, if there are more transition with the same id, only one of those transitions' code is generated.