Research and Development 1/^Archief/2009-2010/08/Logboek
| Datum | Resultaaten | Wie? Wat? Tot wanneer? | Problemen |
|---|---|---|---|
| 10/02/2010 | We hebben er tot nu toe veel over ons project nagedacht. Enkele onderwerpen bleken goede kandidaten.
1: Data Mining / Google Mashup Het is mogelijk, geautomatiseerd de Wishlists van Amazon down te laden en te analyseren. Vervolgens kan men door het linken van de data tegen de gebruikersprofielen en het invoeren daarvan in Google Maps een landkaart genereren en b.v. onderzoeken, in welk regio's welke boeken gekocht worden, wie er een bijzonders interessante/suspecte boekensmaak heeft en andere dingen. Ons doel was dan, deze mogelijkheid te onderzoeken, misschien vergelijkbare oplossingen te ontwikkelen of, iets algemener, andere slimme manieren van het combineren van min of meer vrij verkrijgbare data te bedenken. Probleem: Het bestaat al - van te voren wisten we alleen, dat het in principe mogelijk zou kunnen zijn, maar blijkbaar heeft het al iemand gedaan (engedocumenteert). 2: Indoor Routen Planer Wij gaan een beetje onderzoek doen en een software ontwikkelen die binnen een gebouw een route helpt te vinden. Aan de voorbeeld van de Huygens gebouw. Als dat mogelijk is het best natuurlijk een java (wegens de compatibiliteit) programmaatje voor Windows Mobile mobieltjes.Of iets dergelijks. Verder bestaat er bijvoorbeeld http://www.apple.com/ipod/nike/ . Of wij hebben de mogelijkheid om meters in stappen om te rekenen met een individuele stap lengte. Om distanties te kunnen berekenen. Probleem: Verkrijgen van de blauwdrukken van de gebouwen v/d universiteit 3: Virtual Reality <-> Real Reality Game Een spelletje of meer een concept voor een spelletje. In een lijn zou ik zegen een RCRPG dus een Real Computer Role Play Game. Dat is een grof idee dus zijn jullie inbrengst gevraagd. Je hebt een voorgedefinieerde wereld van kamers of plaatsen (een beetje zo als de AeD opdracht voor deze week.) De verschil of de nieuwheid is de betrekking naar de reale wereld. Je hebt in het best case zo iets als http://www.google.com/mobile/goggles/#landmark en in het begin misschien iets als http://en.wikipedia.org/wiki/QR_Code op bepaalde plekken van een stad of een regio of een land of een continent of de hele wereld. In deze speel kan je opdrachten doen tot een bepaalde punt dan heb je een soort final kamer of eind tegenstander. Voor die is de aanwezigheid op een bepaalde plek nodig. Dat kun je visualiseren tot een digitale nabauw van dit plek waar dan een monster of iets dergelijks verschijnt. In het begin zou het waarschijnlijk text gebaseerd zijn. Je moet er iets bestemd doen, fechten of iets vinden. De toegang naar deze level bekom je maar allen als je op dit bepaalde plek bent. Dit wordt geversificeerd door a) een ingestuurde plaatje zoals Google Goggels, b) een coördinatie van de mobieltje of c) een QR-Code of iet dergelijks. Dus een mogelijkheid de wereld te zien zelfs als je mental in een speel bent en reale plekken serieus te bezoeken. Dus een verschuiving van de VR naar een situatie waar je in de reale wereld bent een de kans hebt door bepaalde geïnstalleerde patterns of beeld patterns of positie toegang te krijgen tot hogere levels. Misschien ook uitbreidbaar. Voorbeeld situatie. Je gaat op vakantie naar London. Oké dan ga je een London deel van de speel downloaden en als je in London bent heb je een sort voor gedefiniëerd attractie lijst die je a) de plek laat zien waar je bent en b) de achtergrond van de speel verder brengt, dus hogere levels of beteer wapen of wat ook... Misschien zou er ook een mogelijkheid te zij de tijd te bepalen, zo dat een plek nachts moet bezoekt worden om de game te triggern of iets dergelijks. Dit dan te realiseren op de campus of misschien zelfs in Nijmegen als wij iets met Picture recognition kunnen verwerken. Anders zou het problematisch zijn QR-Codes op elke plekken aan te brengen of te sproeien ?!? Probleem: 1) Misschien te weinig tijd in R&D 1 om dit te realiseren 2) Herschrijven van de bestaande (tot nu toe onbekende) java library om QR-Codes te kunnen lezen 3) Gedetailleerder concept (<-- goed op te lossen met een beetje nadenken) |
||
| 8/3/2010 |
Inmiddels is er niks gedaan? Jawel. Vlak hierna hebben we nog nagedacht over ideeen en zijn we gekomen met een vierde plan. Namelijk het maken van een digitaal menu voor in restaurants. Het zou hierbij gaan om een apparaat (lees bijv. tablet pc) die mensen per persoon in een restaurant zouden krijgen in plaats van een menu. Hierop zouden zij het menu kunnen zien en zelf hun bestelling doorsturen naar de keuken. Het apparaat is hierbij gelinkt aan een bepaald tafel nummer. Het idee was dat er geen mensen meer nodig waren om bestellingen op te nemen om geld uit te sparen. Behalve het opstellen van dit systeem wilde we een soort korte vragenlijst aan het begin maken, waardoor het menu gefilterd zou worden, totdat er bijvoorbeeld alleen nog maar gerechten op staan voor vegetariers, of dat bepaalde gerechten van de kaart af worden gehaald op het moment dat iemand daar allergisch voor is. Ook kunnen natuurlijk eventueel ingredientlijsten of plaatjes worden toegevoegd aan elk gerecht op het menu. Nadat we begonnen waren aan het onderzoek, het maken van onderzoeksvragen en deze op te zoeken, bleek echter dat iets soortgelijks in amerika al bestaat. Hier is er een touchscreen per tafel die mensen kunnen gebruiken om hun keuze door te sturen naar de keuken. Echter het idee van onze filter methode was daar natuurlijk niet geimplementeerd noch was het per persoon. De vraag is nu, is deze toevoeging genoeg voor ons om het uit te voeren voor R&D1? Eventueel hadden we ook nog een spinoff van het idee om het mogelijk te maken dat mensen vanuit hun eigen pda/telefoon bij bijvoorbeeld een McDrive al kunnen bestellen op het moment dat ze in een bepaalde afstand van het fastfood restaurant is. Bij de McDrive kan men dan gelijk doorrijden zonder die vage communicatie met de medewerker eerst nog te hebben. Dit zouden we ook eventueel verder uit kunnen werken als het eerste idee niet goed is. |
||
| 9/3/2010 |
Een gesprek met de docent om te kijken hoe we het beste verder kunnen, zodat we daarna ook snel de pilot af kunnen ronden en genoeg informatie hebben om aan de slag te gaan. |
Allemaal nadenken hoe nu wat kan. | |
| 10/3/2010 | Vergadering van de groepje met de opvolgende vragen als resultaten, naar een keuze voor die Indoor Routeplanner idee:
Hoe kunnen wij een positie van iemand bepalen binnen een gebouw tijdens de route? Is een grafische weergave mogelijk of werken wij tekst gebaseerd? Hoe gaan wij de realiteit representeren? -De verschillende punten/ Lokalen -De routes -Wat voor datastructuur Hoe berekenen wij het pad tussen de twee locaties? Bestaan er al soortgelijke algoritmes die ons zouden kunnen helpen? |
Iedereen denkt over de vragen lijst na en vind antwoorden of probeert de vragen preciseer te maken. | |
| 18/3/2010 |
We hebben antwoorden gevonden, min of meer, op bovenstaande vragen. Echter zijn nog niet alle vragen volledig beantwoordt. Het belangrijkste waar we nu mee verder moeten is het representeren van de werkelijkheid en het bepalen van iemand's locatie en hiervoor zullen we nog meer overleg en research moeten hebben/doen. |
Op het moment hebben we drie ideeen over het weergeven van de werkelijkheid, namelijk: Waarbij punten op de graaf zowel echte punten als virtuele punten. - Phil Waarbij punten op de graaf alleen echte punten zijn. - Niklas Waarbij punten op de graaf alleen virtueel zijn. - Anne __________________
(L1)/ x1 x2
| _________/ ___
| | (L4)
| |
(L2)/ x3 /(L3)
| |
Waarbij | muren zijn en / een deur.
Ly waarbij y element {1,2,3,4} zijn lokalen.
xz waarbij z element {1,2,3} zijn optionele gang punten.
Elk van deze ideeen wordt door 1 persoon in een testvorm uitgevoerd, om te kijken welke het beste werkt. Tussendoor zal er overleg plaats vinden als iemand problemen heeft met zijn versie. |
|
| 22/04/2010 |
Uit een eerste evaluatie blijkt, dat de variant van het data model, in die alleen echte lokale ook vertices in de graaf worden, niet geschickt is. Het grote nadeel ervan is, dat de bepaalde routes niet zuiver door de gangen lopen, maar de gebruiker van lokaal tot lokaal sturen, wat meer op een speurtocht lijkt. Bijzonders: De richtingsaangaven (links, rechts etc) hebben dan echter ook altijd betrekking op het volgende lokaal, wat voor de gebruiker waarschijnlijk verwarrend zal zijn. Beide andere mogelijkheden (echte lokalen + hulppunten of alleen maar hulppunten) werken echter goed. Het verschill is relatief klein. Vanwegen de betere portabiliteit van Java op andere architectures zullen we dus waarschijnlijk voor Philipps implementatie in Java kiezen. |
Tot volgende week is er per groepslid het volgende te doen: Evalueren van Philipps programma-code + Uitzoeken en op geschiktheid testen van path finding algoritmes |
|
| 27/04/2010 |
Het onderzoek naar geschickte shortest-path-algorithms levert twee goede kandidaten op: Bellman-Ford en Dijkstra. Bellman-Ford heeft als voordeel, zeer makkelijk te implementeren te zijn. Dijkstra daarentegen is iets moelijker, maar ook sneller. We zullen ons programma zo modulair opbouwen, dat we het algoritme simpel kunnen verfangen. Ook A* stond ter discussie, maar werd als te moeilijk voor zo'n eerste versie van het programma beschouwt. Door de eerste drie verschillende versies van het programma te evalueren hebben we nu een aantal dingen gevonden, die goed te werken blijken en die we zeker willen gebruiken in de finale versie:
|
Wegens de meivakantie zullen we pas over twee weken weer ontmoeten. Tijdens deze periode
|
|
| 25/05/2010 |
Wij hebben de code aangepast en veranderingen toegevoegd. Wij hebben besproken hoe het nu verder gaat met de shortest-path-algorithms en hebben de keuze gedaan welke algoritme wij implementeren. Verder hebben wij problemen met meerdere keer rechtdoor gaan gediscuteerd en een oplossing gevonden. Ook de Java Micro Enviroment lijkt nu te werken zo dat de mogelijkheid voor een mobile implementatie een hogere waarschijnlijkheid heeft bekomen. |
||
| 8/06/2010 |
Wij hebben een overleg gehad over het laatste deel van de planning en dus wat er nog moest gebeuren. |
|
