forked from morse-simulator/morse
/
TODO
87 lines (72 loc) · 3.68 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
General TODO list for MORSE
---------------------------
File history:
27/04/2010 - Arnaud + Severin: long list of things to do after the first 6 months of MORSE development
29/04/2010 - Arnaud + Severin: mark with a * things needed for release v0.1
03/05/2010 - Simon: added a "section" related to the management of the frame transformations
04/05/2010 - Arnaud + Severin + Nicolas + Gilberto: review of the list, with aims at a first release
28/05/2010 - Arnaud + Severin: update after "CMake operation"
14/06/2010 - Gilberto: Remove completed tasks
---
Code organisation
-----------------
[DEFERRED] - One repo for scenarii (morse-scenarii.git)
Architecture
------------
* how components access other components? (eg: the cameras need the position of the robot)
* unified time management ("what if we want to simulate at 2X?")
User-interface
--------------
- Graphic tree of logic components and their interaction (no meshes, ... )
- Possibility to control the camera when the game engine runs (with keyboard,
mouse, or attach some view to some robots)
- Use this controllable camera by default when starting a simulation
- [for CHRIS project] Ability to fully control a robot or a human as "first
person shooter" to interact with other robots
Middlewares
-----------
* Rethink the architecture ; three proposals:
[DISCARDED] - Current solution: one abstract interface. Issues: only one middleware at
once ; coupling. In any case, current code must be rewritten (factories,
etc)
[ONGOING] - Components have "hooks" to export their data. Middleware lives in parallel
threads and "visit" the components. In this case, middlewares still lives
in the Python VM. Advantage: better decoupling ; middleware can dynamically
choose what they want to watch.
[DEFFERED] - External decoupling: Python components export their data as shared memory
(or possibly sockets?), external modules (written in any language) read
this memory and format it for each middleware. Advantage: complete decoupling.
If a middleware crashes/slowdowns, no impact on the simulator, language
independant (may be good for Genom3). Issues: "one more copy", could be harder
to manage (one more protocol to manage: what happen if we update the simulator
but not the middleware, etc), debugging, requests harder to implement.
-> Discuss what to do with the "YARP-JSON" bridge from IRIT
* Requests: be sure that components can be remotely (ie by clients) configured
* Add serialize methods to the data of each component. This will format the data according to the needs of each middleware/architecture.
Linking issues
--------------
- when properties are added in linked components (eg, cameras), the new properties
don't show up in the scene that import these components.
Coding style
------------
- code everything in Python 3 compatible Python
- Replace all "print" by the Python logging interface
- every simple function must have a function comment ( """ ... """) + setup the
documentation to be generated
- Change the names of modules, variables, classes, etc. to comply with the
naming conventions in: http://www.python.org/dev/peps/pep-0008/
Frame transformations
-----------
- Representation of all the frames defined within a robot (one frame per sensor,
one robot frame).
- Geo-referenced frames for initial geographic data (define and store a frame
transformation between the Blender reference frame and an abosolute
geo-reference frame)
- Camera geometry: associate a projection matrix to each camera
- Respect the usual standards (e.g. for cameras), define and document the other
choices
Other stuff
-----------
* write, complete, update, add to repo the general documentation of the simulator
- commit policy
- Blender 2.5