These are some suggested subjects. Students may propose others.

For ideas and/or input for the proposals below you can see:

• Instructables technology (look for Arduino or RaspberryPi)
  
• AdaFruit Learn
• Hack A Day (look for Arduino or RaspberryPi)
• Arduino ProjectHub

Some of the projects are in Portuguese (some at the end), please discuss them with your Portuguese group members.

Weighting Cashier

In this project the objective will be to implement supermarket like cashiers to weight objects identified by their RFID tags.

As such, the system should read the tag from the product, while it weights it. The product should be identified and its weight shown on the Android device. The Android device should keep a list of the weighted products. There should be a reset button to re-start the list. As options prices associated with products could be also kept in the products' DB and shown on the list.

There should be at least 2 scales/identifiers and 2 androids showing the lists. The android should choose the scale to read from reading an RFID from the scale itself.

There should be a general station where all the current lists are shown. When a smartphone re-starts a list the general station should move the previous one to archive.

Requirements:

• identification of a product should take less than 2s
• weighting should take less than 2s
  
• product appearing on list (smartphone and general station) should be in less than 2s
  
• the system should support at least 2 smartphones
  
• the system should support at least 2 scales/identifier cashiers
  

Paintings

This project aims to paint on the screen of a smartphone (Android) using interactions in the physical world.

Using joystick, it should be possible to draw lines in the Android screen. Lines could have different colours configured with a button near the joystick.

I should be possible to show the drawing in more than one smartphone at the same time in also on a normal LCD screen. On the LCD screen, it should also be possible to draw with a mouse. Again this should be replicated in all screens (LCD and smartphones).

It should also be possible to use an accelerometer or gyroscope to make lines (in a similar was as with the joystick).

Requirements:

• have more than one Android device;
• have more than one joystick/component to draw;
• drawing starting to appear on screens (LCD or smartphones) since movement made on joystick or mouse should be less than 2s;
• with accelerometer or gyro, should be less than 3s
  
• drawing error (movement from joystick to line drawn) should be less than 5º
• drawing from accelerometer should be less than 45º and in the same direction
• drawing from gyro should be less than 15º and in the same direction

Automatic Lights

In this project light(s) in a room should be turned on when users enter the room and turned off when users exit the room.

The system should detect a specific set of users (more than one) and determine when they enter/leave the room. A welcome message should be displayed for the specific user when (s)he enters the room.

On the Android phone of the user the status of the room's light should be displayed. It should be possible to turn it on/off from the phone. However, the light should not be turned off if a known (in the list) user is in the room. The name of the user (which the system uses for the welcome message) should be defined in the Android phone.

Lights should not be turned on if luminosity on room is above a defined threshold.

Requirements:

• turning on light should be after opening door. Vice-versa for off and door close.
• lights on could be before entering the room
• lights off should be after leaving the room
• user detection should be under 5s
• remotely turning on/off lights should be under 4s since button pressed
• information on phone regarding status of light should be under 4s

Mouse Trap

Here we want to catch a mouse and have a picture of the capture.

There should be a box that detects when something is inside. This should warn the trap's owner on his/hers Smartphone. A picture of what is inside the box should be sent with the alarm. The user will then be able to decide if the box is to be closed or not on the smartphone. If 5 secs after the detection no action is instructed by the smartphone the box should close.

The status of the trap (closed/opened) should be available on the smartphone. It should also be possible to see what is inside the box (request a picture). Closing and opening should be possible on the phone, regardless of detection.

Requirements:

• detection of something inside of box should take less than 2s
• warning sent to owner should take less than 3s
• action to close/open should take effect in less than 3s
  
• there should be more than one mouse trap controlled by the same user/smartphone

Watering from twitter

A plant should also be able to tweet. In this project the plant will tweet (to Twitter®) its humidity, temperature and light. The central part of the system should subscribe to these tweets and react if given thresholds are reached. This reaction will mean notifying the owner of the plant and turning on/off the appropriate actuator.

The owner will have a summary of his/hers plant status and can decide to turn on/off the actuators to correct the status of the plant. He/she can also define/change the thresholds on the smartphone.

Requirements:

• more than one plant monitored;
  
• answer to threshold should be less than 2s;
• reaction to turn on/off from smartphone should be in less than 2s;
• indications to smartphone should reach it in less than 2s.
  

Traffic Control Simulator

To ease the trips of commuters, this project will control the traffic lights in order to reduce queues sizes and time on queues.

The system will track cars queues (that are simulated with potentiometers or push buttons). Longer queues should be given priority (in terms of traffic lighting) to smaller queues. However, smaller queues should also get traffic across (no starvation).
The controlled lights will also include pedestrian crossing, which, naturally, will interact with the streets light. Pedestrians should have buttons to request green light.

The system should represent the amount of cars in a given street by LEDs or other means. This means that by looking at the simulator one can see which streets have more cars. The system should also represent this on the smartphone of a user. The user can change signal lights but not break any rules (both streets in a crossing with green lights; pedestrian and cars with green lights).

Requirements:

• at least one crossing
• pedestrian lights in at least one street
  
• cars should not wait more than 15 sec on a red light;
• system should detect congestion (more than 10 cars stopped at a light) in less than 2s;
  
• queues with 10 or more cars should not have the red light on for more than 10 s

Minecraft Production

Minecrat is a popular game of construction and modelling. In this project we aim to control our Avatar on the Minecraft world using a joystick and buttons. It should be possible to be possible to choose what we want to construct in the world. It should also be possible to destroy objects.

The smartphone can also be used to control the avatar and namely to request the production of a specific object. After construction, the image of what was constructed (screenshot) should be shown on the Android device.

Requirements:

• the time since and order for construction/destruction is given on the smartphone until it happens on the world should be less than 5s
  
• joystick and button movements should be realized on world in less than 2s
• it should be possible to construct at least 3 different objects

Parking Spaces

Here the aim is to manage a parking lot. The objective is to have automatic detection of cars in parking spaces, with a light indication of occupied (red) or free (green). This occupation is to be visualized also on a smartphone. The detection of occupancy should be done by pressure and by infrared (different sensors in different spots).

The system will incorporate a fire alarm (based on temperature and/or light). When a fire is detected the smartphone should be warned and a alarm should sound on the parking site.

On the smartphone it should be possible to reserve a place for parking. This is to be indicated by a different light.

A central system should show the occupancy of the parking site with the license plate for cars that have reserved places (this will be entered in the smartphone).

Requirements:

• support more than one smartphone
• syncing of reservations between smartphones should be in less than 1 sec
  
• detection of car presence should be in less than 1s since arrival
• detection of car absence should be in less than 2s since departure
• indication of change in occupancy in smartphone should be in less than 2s
• same for fire warning
  
• fire detection should be in less than 1s
• indication on parking space (light on) for reservation should be in less than 1s

Indoor Location

To locate objects or persons inside buildings (out of GPS range) one option is to use beaconing systems. This is the aim of this project.

It should be possible to estimate the presence of a person between beacon points. When in range of the beacons the location should be more precise, when out of range of all beacons and estimation based on last movement and on accelerometer and gyroscope input should be used.

The indication of the position should be done on a building plan (blueprint). It should be indicated the arrival at a beacon, which is identified by an ID/code.

It should be possible to trace a route of the person even on places it has no connectivity and/or beacon coverage.

Requirements:

• support more than one person tracking
• estimation should accurate at least at corridor level (in what corridor)
• detection of "at a beacon" should be detected to at least 1 m proximity and never to more than 2.5 m.
• notification of arrival should be in less than 2s

Parking Assistance

This project aims to develop a parking assistance for a car using distance sensors on. The car should use 4 distance sensors and the indication of proximity to obstacles should be shown on a smartphone. The car should have a sound indication with a frequency of beeps increasing with the closeness of an obstacle.

On the smartphone the velocity and time for impact should also be estimated (if speed is maintained). The smartphone should have a "break" control to stop the car (red light on car).

A video or photos of the rear view from the car should also be shown on the smartphone.

Requirements:

• error in distance to obstacle should be in less than 5 cm
• "breaking" should be in less than 2 s
• all obstacles from all sides should be indicated on the smartphone
• images from the rear view should not be delayed more than 1s
  

Avatar Control

Controlling a virtual Avatar using real world interactions has several possibilities. In this project the objective it to animate an Avatar on an Android phone using the movement of a person.

The system should detect the movement of the person's limb (arms and legs) using accelerometers. The movement should be reproduced on the smartphone's Avatar.

The luminosity of the real world should be monitored and reproduce it on the virtual world. If the level of light is too dim a light on the virtual world should be turned on. This should also light a real light. The smartphone should be able to turn on/off the light (real and virtual).

Humidity readings will indicate rain or sunshine (correlated with light) in the virtual world.

Requirements:

• movement of limbs should be detected on at least 2 axis and on the right direction
• raise leg in front or back; raise leg to the side
• turn on/off animations related to sensors in less than 2 s

Enigma Machine

The Enigma machine was a crucial component in the communications of the German forces in WWII, enabling encryption of messages.

This project will have an interface for the Enigma machine that operates (generates the codes) in a processor. As such, there should be buttons for the 26 alpha keys, buttons (or potentiometers, or joysticks) to move the rotors and change order of the dials.

There should be a screen that will show the rotors position and the output will be the resulting keys identified by LEDs.

The resulting coded message should be sent to the smartphone that will decode it using the same principle. The smartphone should show the rotors and allow their configuration.

The smartphone will also be able to produce new rotors and configure them on the machine.

Note that the machine can used to encrypt or decrypt messages.

Requirements:

• coded character should appear in less than 1 s
• message should be received by smartphone in less than 2s
• rotor changes through physical interfaces should react in less than 1 s
• new rotors should be able to be sent in less than 1 s
• there should be at least 3 rotors

Filas de Espera

Neste projeto ir-se-á implementar um sistema para a gestão de filas de espera num guiché de atendimento ao público.

As senhas referentes à posição na fila são "retiradas" utilizando uma aplicação para o smartphone. A aplicação também deve mostrar o número atual a ser atendido.

A pessoa no guiché deve ter um botão para chamar o número seguinte. Será possível visualizar o número corrente no serviço de atendimento. O funcionamento do serviço será com fila única, mesmo com mais do que 1 guiché.

Para validação do número da pessoa apresentado no smartphone deve ser emitido um código numérico na aplicação do smartphone que permita verificar a validade do número de ordem. No atendimento esse número deve ser validado (incluindo o número de ordem), apresentando-se uma luz verde/vermelha de acordo com a correção/incorreção.

Requisitos:

• após pedido de senha na aplicação móvel, a emissão da mesma deve ser em menos de 2s
• a verificação da validade do número da senha deve demorar menos de 2s
• a atualização de todos as aplicações com o número seguinte deve ser inferior a 3s
• o sistema deve suportar mais do que 2 smartphones simultaneamente;
• o sistema deve suportar mais do que 2 guichets simultaneamente;

Câmara na campainha

Este projeto será para colocar uma câmara na porta de uma casa/apartamento.

A câmara deve ser ativada caso se carregar na campainha ou se detetar movimento. Nestes casos as imagens devem ser gravadas com "stop-motion", i.e., com várias fotos em vez de filme de modo a poupar espaço. O sistema para passados 5 minutos de deixar de detetar alguém.

Ao tocar a campainha o utilizador deve ser notificado no seu smartphone. Neste caso ele pode pedir um stream de vídeo sem ser o "stop-motion". No smartphone deve ser possível ver os "stop-motions" gravados e apagar os mesmos. Também deve ser possível acionar a câmara para ver o streaming.

Deve haver uma luz vermelha a indicar que a câmara está a gravar.

Requisitos

• detecção de presença na porta deve ser inferior a 3s;
• início de gravação desde deteção ou toque na campainha deve ser inferior a 3s;
• pedido de stream de video do smartphone deve ter um atraso inferior a 10s
• presença deve ser detetada no mínimo a 50 cm

Abra a Caixa

O objetivo deste projeto será a construção de uma caixa que apenas é aberta de acordo com um código representado por atuações físicas na mesma.

A caixa deve ter um sistema de fecho básico que a mantenha fechada e que a abra quando da introdução do código correto. O código pode ser composto por batidas, rotações, luminosidade, introdução de código numérico, aceleração num dos eixos. A ordem de execução das atuações também faz parte do código. A caixa deve ter uma indicação luminosa de aberta ou fechada, para além do fecho efetivo. A caixa deve emitir um som quando aberta. Deve ser emitido um alarme sonoro/visual se houverem erros consecutivos na introdução do código.

No smartphone deve ser configurado a combinação de códigos que permitem a abertura da caixa. O estado da caixa (aberta ou fechada) deve ser visualizada no smartphone. Deve ser possível saber que partes do código foram já corretamente colocadas. Se houve falhas estas devem ser notificadas no smartphone. No smartphone deve também ser possível abrir e fechar a caixa sem o código. Será possível desligar o alarme no telemóvel.

Requisitos:

• ter pelo menos 3 meios diferentes de introdução de códigos (atuações)
• as notificações para o smartphone sobre as ações na caixa devem ser recebidas desde que foram efetuadas em menos de 5s
• o alarme deve ser ativado após a 3 erros consecutivos em menos de 5 minutos
• a atuação do alarme desde o 3º erro deve ser inferior a 10s

Sensorização da Ponte

Para verificar se as pontes têm problemas estruturais devem-se monitorizar as vibrações associadas às mesmas.

Deve ser possível detetar as vibrações em pontos diferentes da ponte, com a perceção/deteção da gravidade dessa vibração. A indicação do nível de vibração deve ser indicada por luz de diferentes cores.A deteção deve ser feita pela vibração e pela alteração da distância entre pontos da ponte.

No smartphone deve ser possível ver em que pontos e com que gravidade estão a ser detetadas essas vibrações com uma cor idêntica à apresentada na ponte. No smartphone deve ser indicado que tipo de sensor foi ativado e qual o seu valor indicativo. Dever ser possível do smartphone fazer tocar um alarme e acender luzes de perigo na ponte.

Requisitos:

• deteção de vibrações em pelo menos 3 pontos (pelo menos 1 deve ser com vibração e 1 com distância)
• luzes com indicação de gravidade devem ser indicativas para cada ponto monitorizado;
• valores detetados na ponte devem ser recebidos no smartphone com tempo inferior a 5s

Casa Esperta

Na senda da automação das casas, este projeto pretende desenvolver um protótipo (maquete) com essa índole.

A casa deverá ter luzes que sejam acesas quando é detetada a entrada na divisão. Deve ser detetada a saída da casa para apagar as luzes. Caso o sistema automático de luzes esteja ligado, com um nível de luminosidade indicado devem ser acendidas as lâmpadas de toda a casa. Deve ser também indicada a temperatura na casa.

No smartphone deve ser possível visualizar as luzes acesas na casa, acender ou apagar as luzes e ver a temperatura na mesma. A configuração da iluminação automática (on/off) deve ser feita no telemóvel. Deve também ser possível colocar música a tocar usando o telemóvel (música local à casa).

Requisitos:

• a casa deve ter pelo menos 5 divisões com luz;
• após deteção de baixa luminosidade (estando este automatismo on), o sistema deve ligar as luzes em menos de 2s
• comandos do smartphone devem ser repercutidos em ações na casa em menos de 5s

Água pronta

Para se fazer um chá tem de se ir colocar água na chaleira, ligar e depois esperar que a chaleira ferva a água. Neste projeto pretende-se iniciar este processo remotamente.

O sistema deve monitorizar o nível da água, com a indicação por passos (tem menos de 25 cl, entre 25 cl e 50 cl, etc.) ou precisa (tem exatamente 27 cl). Quando for comandada para isso, o aquecimento da água deve ser iniciado pelo sistema e ser detetado a finalização do mesmo. Este início apenas pode ser feito se houver água suficiente na chaleira.

No smartphone deve ter-se a indicação do estado da chaleira: sem água, com água e disponível, a aquecer e neste caso para quantos chás dá a água colocada. Estando disponível e com um nível de água mínimo, deve ser possível iniciar o aquecimento do smartphone. Caso não esteja livre ou com água suficiente esse processo não pode ser iniciado. Caso ainda haja quantidade suficiente água livre para chá, deve ser possível reservar no smartphone essa água. Quando o aquecimento terminar deve ser enviado um sinal para o(s) smartphone(s) que reservou(aram) com sucesso água para o seu chá e tocar um som localmente (à chaleira).

Requisitos:

• o sistema deve suportar pelo menos 3 smartphones a tentar comandar o sistema;
• quando a água estiver pronta todos os smartphones que reservaram com sucesso devem ser avisados em menos de 2s;
• início de ordem para iniciar o aquecimento deve ser inferior a 2s.