Maarten van Kalsbeek en Jeroen van Oorschot: lego mindstorms modem

Uit OstreaWiki

Ga naar: navigatie, zoeken
LogoMJ.jpg

Inhoud

Ons onderwerp

Als onderwerp hebben wij er voor gekozen om een modem te gaan bouwen. In het begin wisten we nog niet of we het met computers moesten gaan doen of met lego mindstorms, maar het is de mindstorms geworden omdat we met de pc software problemen hadden die bijna onoplosbaar zijn. Aangezien wij de modem willen laten communiceren door middel van geluid hebben we software nodig die microfoon input opvangt en verwerkt. De beste programmeertaal hiervoor is visual basic maar zelfs daar is de input verwerken voor professionals moeilijk, dus voor ons al helemaal. Dus zodoende is het lego mindstorms geworden, wat ons als nog voor een zware klus kan stellen mochten we alles helemaal uit werken.

Hoofdvragen en deelvragen

Natuurlijk hoort er bij een PWS ook een hoofdvraag met de daarbij behorende deelvragen. Dit zijn onze hoofd- en deelvragen:

Hoofdvraag

Kunnen wij een communicatie op zetten tussen twee modems die werken op basis van geluid en gemaakt zijn met LEGO Mindstorms?

Deelvragen

Hypothese

Wij verwachten dat we inderdaad een communicatie kunnen opzetten met LEGO Mindstorms door middel van geluid. De frequentie van het geluid zal volgens ons vrij hoog liggen. Dit omdat er weinig interferentie is bij hogere frequenties door achtergrond geluiden en ze moeilijker of niet te horen zijn. We denken dat een eigen verzend methode beter te programmeren is dan morse al zal morse waarschijnlijk sneller zijn. Als beveiliging denken we aan een extra codering zoals een Caesarrotatie of iets meer ingewikkelds. Het automatisch richtsysteem zal misschien niet lukken omdat het vrij lang kan duren om te richten en er veel risico is op storingen.

Plan van aanpak

We zijn van plan om onze deelvragen op volgorde te behandelen, dus om eerst de beste frequentie te bepalen voor de verzending. Het kan zijn dat we de laatste twee deelvragen omwisselen omdat de codering beter te doen zal zijn. Dit is afhankelijk van de hoeveelheid tijd die we hebben.

Taakverdeling

Wie? Wat te doen
Allebei: Onderzoekjes verrichten, testen, presenteren en informatie verzamelen.
Jeroen: Software programmeren (Codes), Logboek bijwerken en Powerpoint maken.
Maarten: Hardware diagrammen maken, hardware bouwen en Wiki bijwerken.

Tijdsplan

Wat wordt er gedaan? Wie gaat het doen? Wanneer wordt het gedaan? Aantal uren?
Onderzoek naar de beste frequentie om geluid mee te verzenden. Allebei Week 40 2 uur
Beginnen met hardwareschema's maken, bouwplan lego maken. Maarten Week 40 12 uur
bedenken en maken van paraboolschotels. Allebei Week 42 4 uur
Start met programmeren software voor LEGO Mindstorms. Jeroen week 40 5 uur
Start met bouwen van Lego structuur aan de hand van bouwplan. Maarten Week 42 4 uur
Software deelvraag 2 en Hardware deelvraag 2 klaar. Allebei Week 42 n.v.t.
Testen en verbeteren van de Modem tot nu toe. Allebei Week 42 3 uur
Onderzoek doen naar verzendmethode: morse of eigen code? Allebei Week 42 6 uur
Software uitbreiden naar deelvraag 4. Jeroen Eind week 42/Begin week 43 20 uur
Hardware uitbreiden naar deelvraag 4. Maarten Eind week 42/Begin week 43 2 uur
Testen en verbeteren van de Modem tot nu toe. Allebei Week 1 3 uur
Codering bedenken voor beveilinging. Maarten Week 2 4 uur
Codering in software programmeren. Jeroen Week 2 4 uur
Testen en verbeteren van de Modem tot nu toe. Allebei Week 4 3 uur
Automatisch richtsysteem bedenken en inbouwen. Maarten Week 4 5 uur
Richtsysteem programmeren in de software. Jeroen Week 4 5 uur
Testen en verbeteren van de Modem tot nu toe. Allebei Week 7/8 3 uur
Powerpoint en presentatie maken en voorbereiden. Allebei Week 9 10 uur
Presentatie houden en alles in leveren. Allebei Week 11 15 min

De tijd tussen het bouwen tot deelvraag 4 en het testen van de modem is zo lang, omdat het 1 van de grootste stukken is die we moeten bouwen. En ook omdat we daartussen geen PWSdagen meer hebben.

Voor Wiki bijwerken trekken we nog 10 uur uit voor Maarten en voor het logboek nog 3 uur voor Jeroen.

Hulpmiddelen

wij maken gebruik van de volgende hulpmiddelen bij het maken van ons PWS:

Concept

Hier staat per deelvraag uitgewerkt hoe we ons modem gemaakt hebben. Soms staat er een verwijzing naar een andere pagina met meer informatie. Dit is om deze pagina overzichtelijk te houden.

Deelvraag 1: Wat is de beste frequentie voor het verzenden?

Het gaat er natuurlijk om dat de frequentie goed wordt opgepakt door de microfoon. Deze microfoon heeft een helaas een beperkt bereik. In onze bronnenlijst hebben we een site waarop iemand een onderzoek heeft gedaan naar de ontvangst van de microfoon. Bij hogere tonen regeert volgens de site de microfoon helaas niet goed. We hopen dit te kunnen overkomen met de parabool spiegels mocht dit zo zijn.

Voor deze proef hebben we een vrij simpel apparaat ontwikkelt dat de geluid sterkte meet (zie afbeelding). Het programma om geluid te meten staat al standaard op de nxt module.

We begonnen onze proef door te kijken op welke frequentie de microfoon het sterkst reageerde. Onze proefopstelling bestond uit een microfoon van de Mindstorms en een luidspreker. De afstand tussen die twee bedroeg bij beide proeven ongeveer 50 cm. Dit gebied lag tussen de 3 en 6 kilohertz. Zie de eerste tabel voor meer detail. De achtergrondruis bedroeg 2% en bij de meeste andere frequenties kwam het geluid niet boven de ruis uit. We zijn met deze waarden verdergegaan. Nu gingen we deze meten terwijl we de microfoon is het ene brandpunt van een paraboolspiegel hingen en de luidspreker in het brandpunt van de andere paraboolspiegel. Opnieuw noteerden we de waardes. Hieruit bleek dat de microfoon het beste opving rond de 4 kilohertz. Zie tabel twee voor meer details. Met deze waarde hebben we nog wat metingen gedaan op grotere afstand en daarbij reageerde de microfoon nog vrij sterk. De afstanden waren 2 meter en 4 meter. Door met een versterker te werken konden de resultaten opgekrikt worden naar 80 tot 100% voor de gekozen sterkte.

Door deze metingen zijn we het er over eens dat we gaan zenden met een frequentie van ongeveer 3,8 tot 3,9 kilohertz.

frequentie in kilohertz gemiddelde sterkte in %
3 9%
3,25 17%
3,5 15.5%
3,75 15.5%
4 12%
4,25 19%
4,5 23%
4,75 16%
5 14,5%
5,25 11%
5,5 13%
frequentie in kilohertz gemiddelde sterkte in %
3 8%
3,25 12%
3,5 17,5%
3,75 24,5%
4 24,5%
4,25 16,5%
4,5 11%
4,75 11%

Deelvraag 2: Kunnen we een signaal sturen van het ene systeem naar het andere systeem?

hardware

Het moeilijkste stuk van deze deelvraag is de hardware aangezien dit al bijna het volledige apparaat is. De volledige basisstructuur hoort bij deze deelvraag. Om te beginnen moeten er schema worden gemaakt waarin staat hoe de stroomkring eruit gaat zien en welke sensoren we gaan gebruiken. verder is er natuurlijk ook een bouwplan nodig waarop de complete structuur staat vermeldt van de LEGO. Deze plannen komen op de pagina Bouwplannen te staan. Buiten deze bouwplannen moet het apparaat natuurlijk ook nog gebouwd worden.

Om te gaan verzenden maken we gebruik van paraboolspiegels. Deze moeten ook gemaakt worden en opgenomen met bevestiging in het bouwplan. aangezien alle parabolen geschikt zijn voor paraboolspiegels, maken we gebruik van de formule Y=X2. Door het gebruik van deze formule kunnen we onze eigen formaten gebruiken en weten we aan de hand van de schaal meteen waar het brandpunt ligt. Ook kunnen we door de spiegels zelf te maken het gewicht laag houden door lichte materialen te gebruiken. Zie voor de rest van de informatie over de parabolen de pagina Paraboolspiegels

We hebben een aantal zoemertjes bekeken die we kunnen gebruiken om een pieptoon te maken. De eerste die we kochten was een wisselstroomzoemertje en konden we dus niet direct aansluiten op de mindstorms. We hebben wel geprobeerd om een soort wisselstroom te maken door een blokgolf als uitgangsspanning in te stellen, maar dat lukte niet goed genoeg om een mooie toon te maken. Voor het onderzoek zie Uitgangsspanning Wel kwam er wat gekraak uit de zoemer. Als tweede hebben we op conrad.nl een gelijkstroomzoemertje gekocht. Deze zou werken van 3 tot 16 volt. Het zoemertje werkte goed met een mooie toon, maar het had een kleine vertraging bij het opstarten en uitschakelen. Daardoor was het niet mogelijk om snel een berichtje te verzenden. De vertraging was ongeveer 200 ms, waardoor we dus alleen een berichtje konden overzenden als we een hele lange periodetijd gebruikten. We hebben een zoemertje opengemaakt om te kijken waardoor deze vertraging kwam. Het bleek dat er elektronica in het zoemertje zit om de toon te maken, en die elektronica zal waarschijnlijk een beetje vertraging opleveren. Omdat die elektronica nodig is om de toon te maken kan dit probleem niet hardwarematig verholpen worden.

software

Het softwaregedeelte bij deze deelvraag is eigenlijk vrij simpel. Het gaat erom dat er een signaal wordt verzonden bij de ene module en dat de andere module het signaal oppikt en aangeeft dat hij een signaal heeft ontvangen. Op deze manier weten we dat een signaal verzenden goed mogelijk is en kunnen we verder met de volgende stap. Kijk voor de volledige code op de pagina Codes. Omdat het om twee verschillende modules gaat zijn er wel twee verschillende programmaatjes nodig, maar zo hou je wel het overzicht in de code.

Deelvraag 3: Wat is de beste verzendmethode?

Protocol

Voor het verzenden van de data is natuurlijk een verzend manier nodig. Dit gaat met piepjes van een bepaalde lengte. We wilden de overweging maken tussen morse en een eigen gemaakte code. Het voordeel van een eigen gemaakte code is dat niemand hem kent en hij moeilijker te onderscheppen/kraken is. Een nadeel van morse is dat de lengte, dat wil zeggen aantal piepjes, varieert. Dit willen we voorkomen, daar het nog al moeilijk te programmeren valt. Vanwege ons typsysteen hebben we besloten voor 36 tekens te gaan( zie deelvraag 4 voor meer details). Voor het systeem is het het beste als alle letters/tekens evenveel piepjes bevatten, maar dat die piepjes in lengte variëren. Verder is het ook van belang dat de transmissie zo snel mogelijk gebeurt, dus dat als alle tekens achter elkaar gezonden worden dit een zo kort mogelijke tijd duurt. We gaan hierbij uit van periodes, omdat we nog niet weten hoelang een periode kan duren. Een periode is de duur van het kortste piepje dat mogelijk is.

We hebben uiteindelijk gekozen voor een systeem waarbij elke letter/teken uit twee piepjes bestaat. De lengte van de piepjes varieert tussen de 1 en de 8 periodes. Zie de pagina Verzendcode voor meer details en berekeningen. De kortste combinaties zullen gebruikt worden voor de meest gebruikte letters om zo de zendtijd zo kort mogelijk te houden en de transmissie dus zo snel mogelijk. De langste combinaties zullen dus logischerwijs worden gebruikt voor de minst gebruikte tekens en letters.

Methode

Ons modem kan het bericht op meerdere manieren verzenden, met directe verbinding, geluid, licht en eventueel nog een andere manier. Een aantal variabelen zijn afhankelijk van de methode, deze staan hieronder.

methode minimale periodetijd
(De kortst mogelijke pulslengte om toch een bericht foutloos te verzenden)
drempelwaarde
(De minimale waarde van de sensor om een signaal als een puls te herkennen)
uitgangsspanning
(De spanning op de verzendpoort)
Direct 30 ms 90% 3%
Geluid 200 ms 75% 25%
Licht 30 ms 50% 3%
Aangepast 500 ms 55% 3%

In alle gevallen blijft de werking van het programma gelijk en al deze methodes gaan volgens het zelfde protocol werken, alleen wel met verschillende periodetijden. Meer informatie daarover staat op de pagina Verzendsnelheid.

Deelvraag 4: Kunnen we een wederzijdse communicatie opzetten die de systemen kunnen verwerken, en hoe maken we dit?

Hardware opbouw

Het apparaat is hier verder ontwikkelt dan in het begin, dus is er ook meer hardware opbouw bij betrokken. Voor de elektronische en standaard bouwplannen kijk je op Bouwplannen.

Gebruikte poorten van de NXT

Omdat deze modules complexer zijn hebben we hier een overzichtje gemaakt met de poorten die we gaan gebruiken in de NXT-module. De Poorten waarbij de tweede kolom leeg is ,zijn nog niet in gebruik. ook de knoppen die we gebruiken op de NXT-module zelf zijn hier aangegeven. In de tweede tabel staan alle kabels van de nieuwe module uitgelegd en de kabels van de oude modules. dit hebben we nodig omdat we met het convertkabeltje gaan werken. We gaan deze op motorpoort B aansluiten, zodat we 2 draden overhouden (zie de tabel hieronder). Op die draden sluiten we dan een zoemertje aan. De spanning op die draden kunnen we van 0 tot 8 volt instellen, om een harder of zachter geluid te maken.

Poort Functie
Sensor 1 Geluidssensor / Lichtsensor
Sensor 2 Tastsensor, bevestigen van een letter
Sensor 3
Sensor 4
Motor A Rotatiesensor, tekst invoer.
Motor B Zoemer voor piepjes / LED voor lichtsignalen.
Motor C Draaimotor voor automatisch richtsysteem
Links pijltje Backspace / Terug / Annuleren knop
Oranje knop Verzend / bevestig knop
Rechts pijltje Hoofdletter knop
Donkergrijze knop Programma beëindigen
Draad Kleur Signaal Convertkabeltje
1 Wit Uitgang1 Draad 1
2 Zwart Uitgang2 Draad 2
3 Rood Aarde
4 Groen 4.3 Volt voeding
5 Geel Tachoteller
6 Blauw Tachoteller

Software opbouw

Deze software is veel uitgebreider dan de eerste versie omdat deze software alles moet kunnen. Je moet letters kunnen kiezen, teksten maken en opmaken, de tekst verzenden en ontvangen. Dit moet ook allemaal in een programmaatje. Dit is bij de software het grootste deel van al het werk omdat het zoveel aspecten zijn waar we rekening moeten houden.

Op 21-10-2011 is het gelukt om de basis software voor het verzenden en ontvangen af te krijgen. Na een aantal verschillende tests is duide lijk gewordet dat beide NXT's kunnen nu berichten sturen en ontvangen. De code waar dit allemaal op draait staat op de pagina Codes. Voor de foto's: Foto's.

De maximale snelheden die we gehaald hebben en de theorie staan op de pagina Verzendsnelheid.

Subdeelvraag 4.1:Hoe maken we een hardwarematig ruisfilter om verstoring van het signaal te voorkomen?

We wilden eigenlijk nog een ruisfilter tussen de geluidssensor en de NXT-module maken, maar dit was helaas niet mogelijk. Voor meer informatie over dit onderwerp zie de pagina Ruisfilter

Deelvraag 5: Automatisch richtsysteem

We gaan geen automatisch richtsysteem maken. Dit is omdat dit niet goed mogelijk is omdat het signaal dat wij verzenden te zwak is om op grotere afstand te kunnen onderscheiden van de omgevingsruis. Op korte afstand heeft een automatisch richtsysteem geen toegevoegde waarde.

Deelvraag 6: Hoe kunnen we ons bericht coderen om interceptie te verminderen?

We willen het bericht niet alleen kunnen versturen, maar we willen ook voorkomen dat iemand ons bericht kan afluisteren. We willen dit op een niet al te ingewikkelde manier doen, maar de codering moet ook niet te kraken zijn met frequentieanalyse. De methode die wij gekozen hebben is een aangepaste Caesarrotatie. De Caesarrotatie zelf is heel gevoelig voor frequentieanalyse, maar wij willen de rotatiewaarde afhankelijk maken van de letterteller. Dan wordt de eerste letter 1x verschoven, de tweede letter 2x verschoven en de derde 3x. Zie de tabel voor meer uitleg. De code kan nu nog wel met computers gekraakt worden, maar niet meer door iemand die ons signaal opvangt. Wat het ook nog moeilijker maakt is dat niet ieder signaal een teken is, wat oorspronkelijk al zorgde voor moeilijkheid bij frequentie analyse.

Letter Caesarrotatie met rotatie 1 Letterteller Caesarrotatie met rotatiewaarde afhankelijk van letterteller.
L M 1 M
E F 2 G
G H 3 J
O P 4 S

Voor de code zie Codes. Door gebruik te maken van deze codering zal de verzendsnelheid achteruit gaan. Dat komt omdat we onze verzendcode zo hadden gemaakt dat de meest gebruikte tekens het snelst verzonden worden. Omdat de tekens verschoven worden zijn de meest gebruikte tekens nu niet meer de tekens die het snelst verzonden worden. Als snelle verzending gewenst is kan daarom de codering uitgezet worden.

Eindproduct

n.n.v.t. (nog niet van toepassing)

Presentatie

De presentatie van ons PWS is op donderdagavond 15 maart.

We gaan onze presentatie ondersteunen met een diavoorstelling en een demonstratie van ons project.

Logboek & Foto's

Zie hier ons logboek om te zien wat we allemaal al gedaan hebben. Deze zullen we regelmatig updaten. Ook maken wij foto's van elk stadium, die staan op de pagina Foto's

Bronnenlijst

Dit zijn de bronnen die wij gebruikt hebben.

Internet

Boeken

Persoonlijke instellingen
Naamruimten
Varianten
Handelingen
Navigatie
Hulpmiddelen