Difference between revisions of "LIFT"

From ATI public wiki
Jump to: navigation, search
Line 1: Line 1:
 
Lift Project is one of the projects designed in department of computer engineering at TTU as a lab project.
 
Lift Project is one of the projects designed in department of computer engineering at TTU as a lab project.
−
The process of this lab is described in Fig. 1.   
+
The process of this lab is described in Fig. 1. Students first have to describe the controller by providing FSM diagrams and transition tables to
 +
the staff and then go through a process of implementation, synthesis and verification. In the end they are required to submit a report.   
 +
 
 
[[File:Process.jpg|600px|thumb|right|alt=Alt text|Fig. 1: Schematic of physical model]]
 
[[File:Process.jpg|600px|thumb|right|alt=Alt text|Fig. 1: Schematic of physical model]]
 +
=Task Description=
 +
 
=Physical Model=
 
=Physical Model=
  
 
==Lego Construction==
 
==Lego Construction==
−
A lego model has been built for this lab. you can see the schematic of the model in Fig. 2.
+
A lego model has been built for this lab. you can see the schematic of the model in Fig. 3.
 
   
 
   
−
[[File:ElevatorModel.jpg|400px|thumb|right|alt=Alt text|Fig. 2: Schematic of physical model]]
+
[[File:ElevatorModel.jpg|400px|thumb|right|alt=Alt text|Fig. 3: Schematic of physical model]]
 +
 
  
−
[[File:IMG_3144.JPG|300px|thumb|right|alt=Alt text|Fig. 3: Stepper motor setup in lego model]]
 
 
=Controller circuit=
 
=Controller circuit=
 
==first prototype==
 
==first prototype==
−
In the first verion of control board, a XULA fpga board has been used. Pin configuration of this board has been shown in Fig. 4.
+
In the first verion of control board, a XULA fpga board has been used. Pin configuration of this board has been shown in Fig. 5.
−
[[File:Schematic.png|400px|thumb|right|alt=Alt text|Fig. 4: Schematic of control board]]
+
[[File:Schematic.png|400px|thumb|right|alt=Alt text|Fig. 5: Schematic of control board]]
−
 
+
−
The following code is the UCF file for XULA board:
+
−
 
+
−
NET "clk" LOC = P43;
+
−
NET "m0" LOC = P56; # Direction
+
−
NET "m1" LOC = P13; # step clock
+
−
NET sleep LOC = P44; # sleep to disable the motor
+
−
+
−
NET "ss(6)" LOC = P37;
+
−
NET "ss(5)" LOC = P36;
+
−
NET "ss(4)" LOC = P57;
+
−
NET "ss(3)" LOC = P61;
+
−
NET "ss(2)" LOC = P62;
+
−
NET "ss(1)" LOC = P50;
+
−
NET "ss(0)" LOC = P52;
+
−
+
−
NET "calls(0)" LOC = P21;
+
−
NET "calls(1)" LOC = P32;
+
−
NET "calls(2)" LOC = P33;
+
−
NET "calls(3)" LOC = P34;
+
−
NET "calls(4)" LOC = P35;
+
−
+
−
NET "menu(0)" LOC = P3;
+
−
NET "menu(1)" LOC = P4;
+
−
NET "menu(2)" LOC = P7;
+
−
NET "menu(3)" LOC = P19;
+
−
NET "menu(4)" LOC = P20;
+
−
+
−
NET "sensors_in(0)" LOC = P39;
+
−
NET "sensors_in(1)" LOC = P68;
+
−
NET "sensors_in(2)" LOC = P82;
+
−
NET "sensors_in(3)" LOC = P97;
+
−
NET "sensors_in(4)" LOC = P94;
+
−
 
+
  
 
The first prototype control board provides the following functionalities:  
 
The first prototype control board provides the following functionalities:  
Line 54: Line 24:
 
* Motor state indicator LEDs
 
* Motor state indicator LEDs
 
* software reset button
 
* software reset button
−
=== Signal Names and Description ===
+
 
−
The first prototype board has the following signals:
+
===System Components, Signal Names and Description ===
 +
[[File:elevator2.png|600px|thumb|right|alt=Alt text|Fig. 2: System Components]]
 +
Top level design entity that students are required to design's interface has been described in the table below:
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
Line 75: Line 47:
 
|}
 
|}
  
−
====Description====
+
The control system itself has different components that have been shown in Fig. 2. In this figure:
−
*Sensors should be designed according to the following functionality (see Fig. 5):  
+
*Counter is a 24 bit counter in the design.
−
[[File:IMG_3145.JPG|300px|thumb|right|alt=Alt text|Fig. 5: Sensor setup on the lego structure]]
+
*Sensors should be designed according to the following functionality (see Fig. 6):  
 +
[[File:IMG_3145.JPG|300px|thumb|right|alt=Alt text|Fig. 6: Sensor setup on the lego structure]]
 
**Sensors are prone to bouncing because of vibrations in the lift which might not be visible to the naked eye but is visible to the sensors. Hence the sensors need to be de-bounced by a three bit shift register with 19th bit of counter slowing the de-bouncing circuit.
 
**Sensors are prone to bouncing because of vibrations in the lift which might not be visible to the naked eye but is visible to the sensors. Hence the sensors need to be de-bounced by a three bit shift register with 19th bit of counter slowing the de-bouncing circuit.
 
**The lift has five ray cut Infra-Red (IR) sensors.
 
**The lift has five ray cut Infra-Red (IR) sensors.
 
**When ever a sensors ray is cut by the lift it sends a signal '1' to the FPGA. Otherwise the sensor sends a '0'
 
**When ever a sensors ray is cut by the lift it sends a signal '1' to the FPGA. Otherwise the sensor sends a '0'
 
**Each sensor is placed between floors and there can be blind spots between each sensor. When the lift is in a blind spot all sensors send "00000" to the FPGA. This is the time when the lift is moving between two sensors. At this point sensors can also recieve value from two sensors as well. (e.g. on the second floor sensors can either have a value "00000" or "00110".) It is recommended that both cases should be handled by the designer. (hint: rather then looking for sensor ="00100" look for sensor(2)= "1".)
 
**Each sensor is placed between floors and there can be blind spots between each sensor. When the lift is in a blind spot all sensors send "00000" to the FPGA. This is the time when the lift is moving between two sensors. At this point sensors can also recieve value from two sensors as well. (e.g. on the second floor sensors can either have a value "00000" or "00110".) It is recommended that both cases should be handled by the designer. (hint: rather then looking for sensor ="00100" look for sensor(2)= "1".)
−
*Motor Signals
+
*Motor should be controlled in the following manner by motor FSM
 +
[[File:IMG_3144.JPG|300px|thumb|right|alt=Alt text|Fig. 4: Stepper motor setup in lego model]]
 
** Motor(0) controls the direction of the motor. Where '1' is DOWN '0' is up
 
** Motor(0) controls the direction of the motor. Where '1' is DOWN '0' is up
−
** Motor(1) generates a clock signal which controls the speed of the motor. The speed is specified by a clk like signal by changing its frequency. The recommended speed of Motor can be given by sending 10th bit of the counter.
+
**Motor(1) generates a clock signal which controls the speed of the motor. The speed is specified by a clk like signal by changing its frequency. The recommended speed of Motor can be given by sending 10th bit of the counter.
−
** A sleep signal turns off the motor. In idle state the motor should be kept turned off. where '1' is ON and '0' is OFF
+
**A sleep signal turns off the motor. In idle state the motor should be kept turned off. where '1' is ON and '0' is OFF
−
** Motor FSM should also shares its Status with Floor FSM ( i.e. idle, going up, going down, blinking Seven segment)
+
**Motor FSM should also shares its Status with Floor FSM ( i.e. idle, going up, going down, blinking Seven segment)
 
*Seven segment should work as follows
 
*Seven segment should work as follows
 
**Seven segment decoder decodes the current floor into seven segment output.
 
**Seven segment decoder decodes the current floor into seven segment output.
 +
**while designing 7seg decoder you should keep in mind that unlike seven segments on Nexys FPGAs you do not need to specify the anode.
 
**Each segment is turned on by logic value 1. Seven segment should also be able to blink 5 times after it reaches a floor.
 
**Each segment is turned on by logic value 1. Seven segment should also be able to blink 5 times after it reaches a floor.
−
**Seven segment the pin orientation (i-e. seven segment <= "abcdefg";)
+
**Unlike nexys 2/3 board's seven segment the pin orientation is opposite. (i-e. seven segment <= "abcdefg";)
 +
**When the elevator reach a particular floor then it should stop and blink the floor number for 5 seconds.
 +
*The Floor FSM should work in the following manner.
 +
**FSM floor calculates the current floor based on the sensor and the Motor FSM status (direction sleep).
 +
**The sensors have blind spots Hence the floor FSM should remember its own floor while passing through the blind spot
  
−
===Safty Monitoring System===
+
===The UCF File===
 +
The following code is the UCF file for XULA board:
 +
 
 +
NET "clk" LOC = P43;
 +
NET "m0" LOC = P56; # Direction
 +
NET "m1" LOC = P13; # step clock
 +
NET sleep LOC = P44; # sleep to disable the motor
 +
 +
NET "ss(6)" LOC = P37;
 +
NET "ss(5)" LOC = P36;
 +
NET "ss(4)" LOC = P57;
 +
NET "ss(3)" LOC = P61;
 +
NET "ss(2)" LOC = P62;
 +
NET "ss(1)" LOC = P50;
 +
NET "ss(0)" LOC = P52;
 +
 +
NET "calls(0)" LOC = P21;
 +
NET "calls(1)" LOC = P32;
 +
NET "calls(2)" LOC = P33;
 +
NET "calls(3)" LOC = P34;
 +
NET "calls(4)" LOC = P35;
 +
 +
NET "menu(0)" LOC = P3;
 +
NET "menu(1)" LOC = P4;
 +
NET "menu(2)" LOC = P7;
 +
NET "menu(3)" LOC = P19;
 +
NET "menu(4)" LOC = P20;
 +
 +
NET "sensors_in(0)" LOC = P39;
 +
NET "sensors_in(1)" LOC = P68;
 +
NET "sensors_in(2)" LOC = P82;
 +
NET "sensors_in(3)" LOC = P97;
 +
NET "sensors_in(4)" LOC = P94;
 +
 
 +
===Safty Monitoring Mechanism===
 
Since this model is designed to be controled remotely, it should be able to maintain its functionality even if it is programmed with a faulty design. For this reason we need some monitoring system to guarantee  
 
Since this model is designed to be controled remotely, it should be able to maintain its functionality even if it is programmed with a faulty design. For this reason we need some monitoring system to guarantee  
 
the functionality.
 
the functionality.
 +
 
====hardware break====
 
====hardware break====
 
A physical switch has been installed on the top floor to prevent faulty designs to go through the roof.   
 
A physical switch has been installed on the top floor to prevent faulty designs to go through the roof.   
 +
 
====behaviour monitor====
 
====behaviour monitor====
 
Since reaching hardware break will require human intervention and it would not always possible (in times that an operator is not present etc.), a behavior monitor system has been added to the lift.
 
Since reaching hardware break will require human intervention and it would not always possible (in times that an operator is not present etc.), a behavior monitor system has been added to the lift.
Line 102: Line 117:
 
takes over the control and brings the lift to the initial position and sends a reset signal to the control board.
 
takes over the control and brings the lift to the initial position and sends a reset signal to the control board.
  
−
= Lab Reports =
+
 
−
Students are required to submit a report in the beginning before starting their designs to describe the process of what they are planning to do and one at the end of the lab along with their codes. How ever a lab report template has been provided for students. You can find it here: [[:File:lab6_template.pdf]]
+
 
=Testing=
 
=Testing=
 +
After students finished their design they are required to perform tests on their designs firs by simulating it and then try it on the physical model.
 
== Simuation ==
 
== Simuation ==
 +
===VHDL Simulation===
 
A VHDL testbench has been designed to be used for verifying the functionality of the lift.  
 
A VHDL testbench has been designed to be used for verifying the functionality of the lift.  
 +
 +
===Verilog Simulation===
 +
Students are required to write a Verilog testbench to test their designs.
 +
 
== Remote Lab ==
 
== Remote Lab ==
 
in this project, a remote lab was designed for students to access the controlling hardware from any remote place inside the department INTERA network.
 
in this project, a remote lab was designed for students to access the controlling hardware from any remote place inside the department INTERA network.
Line 112: Line 132:
 
A working sample of the controller is provided to the students as a demo in order to get them accustomed to the functionality of the Lift.
 
A working sample of the controller is provided to the students as a demo in order to get them accustomed to the functionality of the Lift.
 
you can access this lab from this link: [[cherry.pld.ttu.ee]]
 
you can access this lab from this link: [[cherry.pld.ttu.ee]]
 +
 
=== Web Server ===
 
=== Web Server ===
 
*server on Raspberry Pi
 
*server on Raspberry Pi
Line 118: Line 139:
  
 
=== Push button emulator ===
 
=== Push button emulator ===
−
*using Raspberry Pi GPIO for emulating push button behaviour
+
*using Raspberry Pi GPIO for emulating push button behaviour.
 +
 
 +
= Lab Reports =
 +
Students are required to submit a report in the beginning before starting their designs to describe the process of what they are planning to do and one at the end of the lab along with their codes. A lab report template has been provided for students (You can find it here: [[:File:lab6_template.pdf]]) and all the reports should be submitted in the same format.
  
−
=Future Work=
+
=Future plans for improvement=
 
* queueing system for login in remote lab
 
* queueing system for login in remote lab
 
* checking the bitfile for malicious code
 
* checking the bitfile for malicious code

Revision as of 17:14, 3 December 2014

Lift Project is one of the projects designed in department of computer engineering at TTU as a lab project. The process of this lab is described in Fig. 1. Students first have to describe the controller by providing FSM diagrams and transition tables to the staff and then go through a process of implementation, synthesis and verification. In the end they are required to submit a report.

Alt text
Fig. 1: Schematic of physical model

Task Description

Physical Model

Lego Construction

A lego model has been built for this lab. you can see the schematic of the model in Fig. 3.

Alt text
Fig. 3: Schematic of physical model


Controller circuit

first prototype

In the first verion of control board, a XULA fpga board has been used. Pin configuration of this board has been shown in Fig. 5.

Alt text
Fig. 5: Schematic of control board

The first prototype control board provides the following functionalities:

  • Seven segment display
  • Inner and outer cabin push buttons
  • Motor state indicator LEDs
  • software reset button

System Components, Signal Names and Description

Alt text
Fig. 2: System Components

Top level design entity that students are required to design's interface has been described in the table below:

Name Port type
clk in STD_LOGIC
sensors in STD_LOGIC_VECTOR (4 DOWNTO 0)
calls in STD_LOGIC_VECTOR (4 DOWNTO 0)
menu in STD_LOGIC_VECTOR (4 DOWNTO 0)
motor out STD_LOGIC_VECTOR (1 DOWNTO 0)
sleep out STD_LOGIC
Seven segment out STD_LOGIC_VECTOR (6 DOWNTO 0)

The control system itself has different components that have been shown in Fig. 2. In this figure:

  • Counter is a 24 bit counter in the design.
  • Sensors should be designed according to the following functionality (see Fig. 6):
Alt text
Fig. 6: Sensor setup on the lego structure
    • Sensors are prone to bouncing because of vibrations in the lift which might not be visible to the naked eye but is visible to the sensors. Hence the sensors need to be de-bounced by a three bit shift register with 19th bit of counter slowing the de-bouncing circuit.
    • The lift has five ray cut Infra-Red (IR) sensors.
    • When ever a sensors ray is cut by the lift it sends a signal '1' to the FPGA. Otherwise the sensor sends a '0'
    • Each sensor is placed between floors and there can be blind spots between each sensor. When the lift is in a blind spot all sensors send "00000" to the FPGA. This is the time when the lift is moving between two sensors. At this point sensors can also recieve value from two sensors as well. (e.g. on the second floor sensors can either have a value "00000" or "00110".) It is recommended that both cases should be handled by the designer. (hint: rather then looking for sensor ="00100" look for sensor(2)= "1".)
  • Motor should be controlled in the following manner by motor FSM
Alt text
Fig. 4: Stepper motor setup in lego model
    • Motor(0) controls the direction of the motor. Where '1' is DOWN '0' is up
    • Motor(1) generates a clock signal which controls the speed of the motor. The speed is specified by a clk like signal by changing its frequency. The recommended speed of Motor can be given by sending 10th bit of the counter.
    • A sleep signal turns off the motor. In idle state the motor should be kept turned off. where '1' is ON and '0' is OFF
    • Motor FSM should also shares its Status with Floor FSM ( i.e. idle, going up, going down, blinking Seven segment)
  • Seven segment should work as follows
    • Seven segment decoder decodes the current floor into seven segment output.
    • while designing 7seg decoder you should keep in mind that unlike seven segments on Nexys FPGAs you do not need to specify the anode.
    • Each segment is turned on by logic value 1. Seven segment should also be able to blink 5 times after it reaches a floor.
    • Unlike nexys 2/3 board's seven segment the pin orientation is opposite. (i-e. seven segment <= "abcdefg";)
    • When the elevator reach a particular floor then it should stop and blink the floor number for 5 seconds.
  • The Floor FSM should work in the following manner.
    • FSM floor calculates the current floor based on the sensor and the Motor FSM status (direction sleep).
    • The sensors have blind spots Hence the floor FSM should remember its own floor while passing through the blind spot

The UCF File

The following code is the UCF file for XULA board: 

NET "clk" LOC = P43;
NET "m0" LOC = P56; # Direction 
NET "m1" LOC = P13; # step clock
NET sleep LOC = P44; # sleep to disable the motor

NET "ss(6)" LOC = P37;
NET "ss(5)" LOC = P36;
NET "ss(4)" LOC = P57;
NET "ss(3)" LOC = P61;
NET "ss(2)" LOC = P62;
NET "ss(1)" LOC = P50;
NET "ss(0)" LOC = P52;

NET "calls(0)" LOC = P21; 
NET "calls(1)" LOC = P32;
NET "calls(2)" LOC = P33;
NET "calls(3)" LOC = P34;
NET "calls(4)" LOC = P35;

NET "menu(0)" LOC = P3;
NET "menu(1)" LOC = P4;
NET "menu(2)" LOC = P7;
NET "menu(3)" LOC = P19;
NET "menu(4)" LOC = P20;

NET "sensors_in(0)" LOC = P39;
NET "sensors_in(1)" LOC = P68;
NET "sensors_in(2)" LOC = P82;
NET "sensors_in(3)" LOC = P97;
NET "sensors_in(4)" LOC = P94;

Safty Monitoring Mechanism

Since this model is designed to be controled remotely, it should be able to maintain its functionality even if it is programmed with a faulty design. For this reason we need some monitoring system to guarantee the functionality.

hardware break

A physical switch has been installed on the top floor to prevent faulty designs to go through the roof.

behaviour monitor

Since reaching hardware break will require human intervention and it would not always possible (in times that an operator is not present etc.), a behavior monitor system has been added to the lift. Motor control signals goes through the monitoring system and if it detects a suspicious behaviour (being on first floor and unwinding the thread or being on the top floor and trying to move up) it takes over the control and brings the lift to the initial position and sends a reset signal to the control board.


Testing

After students finished their design they are required to perform tests on their designs firs by simulating it and then try it on the physical model.

Simuation

VHDL Simulation

A VHDL testbench has been designed to be used for verifying the functionality of the lift.

Verilog Simulation

Students are required to write a Verilog testbench to test their designs.

Remote Lab

in this project, a remote lab was designed for students to access the controlling hardware from any remote place inside the department INTERA network. The server is running on a raspberry pi and students can see a view of the working lift using an internet camera. A working sample of the controller is provided to the students as a demo in order to get them accustomed to the functionality of the Lift. you can access this lab from this link: cherry.pld.ttu.ee

Web Server

  • server on Raspberry Pi
  • username and password for restrictions on access
  • internet webcam

Push button emulator

  • using Raspberry Pi GPIO for emulating push button behaviour.

Lab Reports

Students are required to submit a report in the beginning before starting their designs to describe the process of what they are planning to do and one at the end of the lab along with their codes. A lab report template has been provided for students (You can find it here: File:lab6_template.pdf) and all the reports should be submitted in the same format.

Future plans for improvement

  • queueing system for login in remote lab
  • checking the bitfile for malicious code
  • making a 3D model for printing
  • providing access for students outside ATI interanet
  • PCB design for control board
  • adding a micro-controller based control board
  • monitoring all the sensors in monitoring system
Retrieved from "https://strudel.pld.ttu.ee/wiki/e/index.php?title=LIFT&oldid=1835"