Offene Punkte - Pflichtenheft

[GoogleCodeExporter]

- Auflösung der Anwendung am Android Emulator testen
- Langtexte ergänzen
- Art der Roboterauswahl auf dem Smartphone klären
- Identifikation der kritischen Bereiche abklären

Original issue reported on code.google.com by andreas....@gmx.com on 6 Oct 2010 at 1:00

[GoogleCodeExporter]

Dürfen nach Beginn des Erkundungsvorgangs noch neue e-pucks dazukommen? Oder 
soll das System nur mit ausfallenden e-pucks zurecht kommen?

Original comment by andreas....@gmx.de on 7 Oct 2010 at 8:47

[GoogleCodeExporter]

Sollen wir bei der Beschreibung des Spielfeldes aufnehmen dass die Quadrate 
zwingend die Größe eines e-pucks haben? Oder sollen wir das als 
Mindestgröße eines Feldes  angeben?

Original comment by andreas....@gmx.de on 7 Oct 2010 at 8:59

[GoogleCodeExporter]

Ich würde vorschlagen dass wenn der Erkundungsvorgang einmal gestartet ist 
keine neuen ePucks mehr dazukommen dürfen... das würde die arbeit ziemlich 
erschweren. 
Dies müsste man dann wohl noch in die Abgrenzungskriterien eintragen. 

Original comment by f.buerch...@googlemail.com on 7 Oct 2010 at 10:22

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

@ Comment 1 
Bin auch dafür,dass keine neuen dazukommen,das hätte den Vorteil dass wir nur 
einmal am Anfang die wirkliche "Erkundungstour" der einzelnen epucks per 
Algorithmus berechnen lassen

@ Comment 2
Würde sagen wenn es keinen Mehraufwand nach sich zieht nur die Mindestgröße, 
das kommt glaub ich besser

Wie seht ihr das?

Original comment by lorenz.florian@googlemail.com on 7 Oct 2010 at 10:47

[GoogleCodeExporter]

Naja, aber wenn man die Anzahl nicht dynamisch wachsen lassen kann, hat man das 
Problem, dass auch ausgefallene e-pucks oder soclhe, die die verbindung 
verloren haben nicht mehr berücksichtigt werden können.

Original comment by andreas....@gmx.de on 7 Oct 2010 at 10:57

[GoogleCodeExporter]

1) Änderung der ePuckanzahl
Die Bedingung für die Aufnahme weiterer ePucks während der Erkundung ist, 
dass ein dynamischer Lokalisierungalgorithmus vorhanden ist, um die Position 
der zusätzlichen ePucks zu bestimmen.

Unter der Annahme, dass dies der Fall ist, wird die Aufgabe dadurch nicht 
komplexer. Die Explorationswege müssen sowieso ständig neu berechnet werden 
und der (nicht gleichzeitige) Ausfall und Wiedereintritt mehrerer ePucks muss 
auch berücksichtigt werden.

Daher eher ein erfüllbares Wunschkriterium.

2) Spielfeld
Z.B.: "Die Grundeinheit des Spielfeldes ist ein Quadrat, das einen ePuck 
komplett umgibt. Dieses Quadrat ist wiederum in vier Quadrate unterteilt."
Ich sehe keine Probleme darin, wenn das Einheitsquadrat über der 
Mindestgröße liegt.

Original comment by martin.f...@gmail.com on 7 Oct 2010 at 11:02

[GoogleCodeExporter]

1) Änderung der e-puck-Anzahl
Sehe ich genauso wie Moartl, falls wir das Wunschkriterium mit den belibigen 
Startpositionen erfüllen, dann ist dieses Wunschkriterium auch nicht viel 
Mehraufwand.

2) Spielfeld
Bedenkt bitte die Situation mit den festen Startpositionen. Falls die Knoten 
beliebig weit voneinander entfernt sind, so können wir uns nicht allein auf 
die IR-Sensoren verlassen. Wir müssen dann eventuell erst von jedem Roboter 
aus in jede Richtiung einen Knoten abfahren, um zu sehen ob ein Nachbar da ist.

@alle: Wäre es nicht schöner, wenn wir doch pro offfenen Punkt einen neuen 
"Issue" im Google-Code aufmachen? Macht das ganze auf Dauer übersichtlicher 
und wir vergessen nix. Man kann dafür auch ein eigenes kleines Template machen

Original comment by andreas....@gmx.com on 7 Oct 2010 at 12:01

[GoogleCodeExporter]

zu 2)
Wenn die Startpositionen fest vergeben sind (z.B Roboter in einer Linie, von 
links nach rechts nach steigender Priorität sortiert), dann wären wir 
komplett unabhängig von den IR-Sensoren.
An sich legt der Lokalisierungalgorithmus fest, welche Bedingungen an das 
Spielfeld erfüllt sein müssen.

Man kann hier leider keine Issues spalten; es wäre aber definitiv angebracht.

Original comment by martin.f...@gmail.com on 7 Oct 2010 at 12:12

[GoogleCodeExporter]

Original comment by andreas....@gmx.com on 8 Oct 2010 at 12:19

• Added labels: Type-Open
• Removed labels: Type-Defect

[GoogleCodeExporter]

- Kalibrierung muss eingefügt werden ins EEPROM (Funktionalität)
- Funkionalität: Kollisionsauflösung
- Drehungen nur auf Knoten!

Original comment by andreas....@gmx.com on 12 Oct 2010 at 6:58

[GoogleCodeExporter]

Jens fragen: 

- sollen wir wirklich kritische Bereiche berücksichtigen?
- sollen Dialoge, die zu Wunschfunktionen gehören (Statistik) im Pflichtenheft 
erscheinen?

Original comment by andreas....@gmx.com on 13 Oct 2010 at 11:47

[GoogleCodeExporter]

Original comment by andreas....@gmx.com on 22 Nov 2010 at 8:36

• Changed state: Fixed