Kart/Sensors

(Difference between revisions)
Jump to: navigation, search
(FPGA design)
(Testing)
(8 intermediate revisions by one user not shown)
Line 72: Line 72:
 
}}
 
}}
 
* When '''zeroPos''' goes to '1', the corresponding counter value must be immediately reset on the next clock
 
* When '''zeroPos''' goes to '1', the corresponding counter value must be immediately reset on the next clock
 +
*''The signal '''hallChanged''' is unused.''
  
 
{{TaskBox|content=
 
{{TaskBox|content=
 
Draw the schematics of the <code>hallCounters</code> block.
 
Draw the schematics of the <code>hallCounters</code> block.
 
}}
 
}}
 +
 +
=== Testing ===
 +
See [[Kart/Sensors#Testing_3|Testing chapter]].
  
 
== Ultrasound ranger ==
 
== Ultrasound ranger ==
Line 98: Line 102:
  
 
==== FPGA design ====
 
==== FPGA design ====
 +
[[File:Kart_ranger_block.jpg|right|600px|hall sensors block]]
  
 
To begin with, the [[Kart#FPGA_Design|design environment]] has to be downloaded.
 
To begin with, the [[Kart#FPGA_Design|design environment]] has to be downloaded.
 +
 
It comprises the <code>sensorsController</code> block which contains the registers and events manager
 
It comprises the <code>sensorsController</code> block which contains the registers and events manager
 
and an empty <code>ultrasoundRanger</code> block which is to be completed.
 
and an empty <code>ultrasoundRanger</code> block which is to be completed.
  
The <code>rangerSubsignals</code> block is responsible to transmit the pulse internally only 3 times per second and to synchronize the signals to the beginning of the pulse.
+
The <code>rangerSubsignals</code> block has the following behavior:
 +
* It gets the raw '''distancePulse''' signal, continuously coming in as the sensor is configured to always take measurements
 +
* Around each 333 ms, it waits for a fresh measurement (i.e. '''distancePulse''' falling edge indicates the end of the current measure)
 +
* The '''countEnable''' signal will then rise to indicate we have to count the pulse
 +
* The '''countPulse''' will create pulses each 1 ms, that must be counted (it is not possible to count the clock directly, otherwise the [[kart/serial link#Registers|register]] may overflow)
 +
* '''countEnable''' will then fall at the end of the measurement, then the block waits another 333 ms to repeat the process
  
It creates two signals:
 
*<code>countEnable</code>, which stays at '1' the length of the measurement
 
*<code>countPulse</code>, which are small pulses that must be counted, dividing the clock by a factor 10 (else the total count may be bigger than its corresponding [[kart/serial link#Registers|register]])
 
  
The block <code>ultrasoundRanger</code> has the following flow:
+
The block <code>ultrasoundRanger</code>, which must be completed, has the following flow:
* wait for the signal <code>countEnable</code> to be '1'
+
* Wait for the signal <code>countEnable</code> to be '1'
* when so, the pulses <code>countPulse</code> must be counted as long as <code>countEnable</code> is '1'
+
* When so, the pulses <code>countPulse</code> must be counted as long as <code>countEnable</code> is '1'
* when it goes back to '0', the counter value must be output to the <code>distance</code> signal and the counter reset, waiting for <code>countEnable</code> to go back to '1'
+
* When it goes back to '0', the counter value must be output to the <code>distance</code> signal and the counter reset, waiting for <code>countEnable</code> to go back to '1'
 +
{{WarningBox|content=
 +
The signal '''rangerDistance''' must be updated only when '''reset = '1'''' or when '''countPulse falls''', the signal being kept intact until the next measurement is completed.
 +
}}
  
 
{{TaskBox|content=
 
{{TaskBox|content=
 
Draw the schematics of the <code>ultrasoundRanger</code> block.
 
Draw the schematics of the <code>ultrasoundRanger</code> block.
 
}}
 
}}
 +
 +
=== Testing ===
 +
See [[Kart/Sensors#Testing_3|Testing chapter]].
  
 
== End of turn switch ==
 
== End of turn switch ==
Line 223: Line 237:
 
** <code>set_io {SDA_proxy[1]} -pinname 28 -fixed yes -DIRECTION InOut -RES_PULL Up</code>
 
** <code>set_io {SDA_proxy[1]} -pinname 28 -fixed yes -DIRECTION InOut -RES_PULL Up</code>
 
** ''{SDA_proxy[n]} with n from 1 to NUMBER_OF_PROXIMITY_SENSORS''
 
** ''{SDA_proxy[n]} with n from 1 to NUMBER_OF_PROXIMITY_SENSORS''
 +
 +
== Testing ==
 +
The Hall sensor functionality can be tested through the '''Sensors_test -> sensors_tb''' block.
 +
 +
[[File:Kart_sensors_tester.jpg|center|600px|sensors tester]]
 +
 +
The corresponding simulation layout file for Modelsim is available under '''$SIMULATION_DIR/Sensors/sensors.do'''.
 +
It will automatically run the simulation if it has not been modified.
 +
 +
[[File:Kart_sensors_tester_sim.jpg|right|1000px|sensors tester sim]]
 +
 +
* The '''blue''' header shows which test is performed
 +
* The '''yellow''' signals are those generated by the tester
 +
* The '''purple''' signals are the one generated by your implementation
 +
* ''You can add and remove signals at will, they will not interfere with the tests''
 +
 +
=== Tests ===
 +
The following tests are performed for the Hall sensors:
 +
* For each sensor, a pulse of a fixed period (n times slower for each new sensor) is generated
 +
* The '''hallCount''' is compared to an internal counter, depending on the '''HALLSENS_2PULSES_PER_TURN''' constant
 +
* When '''zeroPos''' goes to '1', the '''hallCount''' should be reset
 +
 +
The following tests are performed for the Ranger:
 +
* A pulse of '''tbRangerDistanceTarget (1012)''' * (clockPeriod / 10)  will be generated
 +
* When the signal '''distancePulse''' falls, the '''rangerDistance''' should be updated with a value of 1011 to 1013
 +
 +
The '''transcript''' window gives you details on if tests passed or not:
 +
* For the '''hallCount''' signal, you get <code>Hall count ''n'' OK</code> or <code>Hall count ''n'' error</code>.
 +
* For the '''rangerdistance''' signal, you get <code>Ultrasound ranger OK</code> or <code>Ultrasound ranger error</code>.
  
 
[[Category:Kart]]
 
[[Category:Kart]]

Revision as of 11:49, 4 July 2022

Contents

Sensors module

Various sensors can be mounted on the motherboard through the exposed PMOD connectors.


Hall sensors

One or two Hall sensors are used to track the distance driven by the kart.

The SS311PT/SS411P digital Hall-effect sensors are operated by a magnetic field and designed to respond to alternating North and South poles with their Schmitt-trigger output.

They can be powered between 2.7 Vdc to 7 Vdc, with an open collector output (which integrates a 10 kOhm pull-up resistor already).

Thus it can be operated through any PMOD by wiring it such as:

Color Pin
Red 3.3 V power supply
Brown Hall output
Black GND

Dialog-warning.png

No internal pull resistor should be enabled on the FPGA side.

Operating procedure

To enable and root the hall sensors, proceed as follow:

  • Modify the Kart/Kart_Student package variable NUMBER_OF_HALL_SENSORS to the number of used hall sensors
  • Modify the .pdc file to root the halls to the desired pins
    • set_io {halls[1]} -pinname 86 -fixed yes -DIRECTION Input
    • {halls[n]} with n from 1 to NUMBER_OF_HALL_SENSORS

FPGA design

hall sensors block

To begin with, the design environment has to be downloaded.

It comprises the sensorsController block which contains the registers and events manager and an empty hallCounters block which is to be completed.

The hallPulsesFilter block does the following:

  • It receives the raw pulses from the hall sensors
  • It debounces the input to avoid false-transitions
  • It finally transmits the filtered pulses


The hallCounters block then receives the hallPulses signal array (i.e. one signal per hall pulse sensor, from 1 to NUMBER_OF_HALL_SENSORS).

The following behavior must be implemented:

  • While zeroPos (also from 1 to NUMBER_OF_HALL_SENSORS) is '1' for a sensor, reset the pulses count
  • Then, if '0', the dedicated counter must be incremented on either:
    • The rising edge of the pulse
    • Both the rising and falling edges of the pulse

Dialog-warning.png

Please modify the Kart/Kart_Student package variable HALLSENS_2PULSES_PER_TURN to '1' if the signal is counted on each edge or '0' if counted only on the rising edge.

  • The counters values must be concatenated to the hallCount signal (e.g. for 2 sensors : hallCount = (COUNTER2 << 16) + COUNTER1)

Dialog-warning.png

The output hallCount must ALWAYS reflect the current counters values

  • When zeroPos goes to '1', the corresponding counter value must be immediately reset on the next clock
  • The signal hallChanged is unused.


View-pim-tasks.png

Draw the schematics of the hallCounters block.

Testing

See Testing chapter.

Ultrasound ranger

An ultrasound ranger can detect if there is an obstacle at the front or back of the kart.

It is based on the PMOD-MAXSONAR board from Digilent, and can be plugged into any one-row PMOD connector (beware not to wire on the +12V pin !).

The ranger will output a pulse named PW on the board whose length has to be counted to determine the distance to an object following the rule 147 us / inch. Since the start/stop pin is not reachable, the sensor will continuously output pulses between 0.88 and 37.5 ms, each 49 ms.

Dialog-warning.png

No internal pull resistor should be enabled on the FPGA side.

Operating procedure

To root the ranger, proceed as follow:

  • Modify the .pdc file to root the ranger to the desired pin
    • set_io distancePulse -pinname 63 -fixed yes -DIRECTION Input
    • The pin must correspond to the PW pin on the ranger board

FPGA design

hall sensors block

To begin with, the design environment has to be downloaded.

It comprises the sensorsController block which contains the registers and events manager and an empty ultrasoundRanger block which is to be completed.

The rangerSubsignals block has the following behavior:

  • It gets the raw distancePulse signal, continuously coming in as the sensor is configured to always take measurements
  • Around each 333 ms, it waits for a fresh measurement (i.e. distancePulse falling edge indicates the end of the current measure)
  • The countEnable signal will then rise to indicate we have to count the pulse
  • The countPulse will create pulses each 1 ms, that must be counted (it is not possible to count the clock directly, otherwise the register may overflow)
  • countEnable will then fall at the end of the measurement, then the block waits another 333 ms to repeat the process


The block ultrasoundRanger, which must be completed, has the following flow:

  • Wait for the signal countEnable to be '1'
  • When so, the pulses countPulse must be counted as long as countEnable is '1'
  • When it goes back to '0', the counter value must be output to the distance signal and the counter reset, waiting for countEnable to go back to '1'

Dialog-warning.png

The signal rangerDistance must be updated only when reset = '1' or when countPulse falls, the signal being kept intact until the next measurement is completed.


View-pim-tasks.png

Draw the schematics of the ultrasoundRanger block.

Testing

See Testing chapter.

End of turn switch

The end of turn switch can be plugged into any PMOD connector, respecting the following:

Color Pin
Green PMOD I/O
Black GND

Dialog-warning.png

An internal pull-up must be enabled on the FPGA side.

Operating procedure

To root the switch, proceed as follow:

  • Modify the .pdc file to root the switch to the desired pin
    • set_io stepperEnd -pinname 97 -fixed yes -DIRECTION Input -RES_PULL Up

LEDs / Low-consumption outputs

In addition to the 3 indication LEDs present on the daughterboard, one can use any PMOD to drive LEDs or other outputs requiring either ON, OFF, or 50% duty cycle PWM (from 1 to 16383 ms) output.

Dialog-warning.png

The consumption per pin cannot be higher than 8 mA.

If needed, use a driver extension board to control voltages other than 3.3V or higher currents (through MOSFETs).

Check with your supervisor before wiring custom systems. I/O lines are NOT protected against over current and voltage backfeed. You are held responsible for the cost of repair in the event of destruction of the equipment (up to 50CHF per board).

Operating procedure

On the FPGA side, those outputs are called leds[n]. To root them, proceed as follow:

  • Modify the Kart/Kart_Student package variable NUMBER_OF_LEDS to correspond to how many outputs are used
  • Modify the .pdc file to root the leds to the desired pins
    • set_io {leds[1]} -pinname 78 -fixed yes -DIRECTION Output
    • {leds[n]} with n from 1 to NUMBER_OF_LEDS

Buttons / Digital inputs

Buttons or other digital inputs can be wired to any PMOD as long as their levels are in the range 0-3.3V !

An event is sent to the smartphone each time the input is rising or falling.

Dialog-warning.png

Inputs are not suitable for signals faster than 5 Hz.

By the design and use of a BLE system, the transmission channel would become congested.

Operating procedure

On the FPGA side, those inputs are called endSwitches[n]. To root them, proceed as follow:

  • Modify the Kart/Kart_Student package variable NUMBER_OF_EXT_END_SWITCHES to correspond to how many inputs are used
  • Modify the .pdc file to root the inputs to the desired pins
    • set_io {endSwitches[1]} -pinname 64 -fixed yes -DIRECTION Input
    • {endSwitches[n]} with n from 1 to NUMBER_OF_EXT_END_SWITCHES
    • If needed, one can add -RES_PULL Up or -RES_PULL Down to use internal pull resistors

Proximity sensors

The proximity sensors are used to get the ambient light along the close proximity to an object. They can be plugged in any PMOD.

They are normally not used anymore and thus not tested in the current Kart project.

The sensor cable is to be connected as:

Color Pin
Orange 3.3 V power supply
Yellow SDA
Green SCL
Blue ground

Dialog-warning.png

External pull-ups should be present on the sensor board I2C lines, else internal ones enabled on the FPGA side.

Operating procedure

To root them, proceed as follow:

  • Modify the Kart/Kart_Student package variable NUMBER_OF_PROXIMITY_SENSORS to correspond to how many sensors are used
  • Modify the .pdc file to root the SCL to the desired pin(s)
    • set_io SCL_proxy -pinname 27 -fixed yes -DIRECTION Input -RES_PULL Up
    • if using multiple sensors and the SCL pins cannot be wired to the same output, root the SCL_proxy to multiple pins
  • Modify the .pdc file to root the SDAs to the desired pins
    • set_io {SDA_proxy[1]} -pinname 28 -fixed yes -DIRECTION InOut -RES_PULL Up
    • {SDA_proxy[n]} with n from 1 to NUMBER_OF_PROXIMITY_SENSORS

Testing

The Hall sensor functionality can be tested through the Sensors_test -> sensors_tb block.

sensors tester

The corresponding simulation layout file for Modelsim is available under $SIMULATION_DIR/Sensors/sensors.do. It will automatically run the simulation if it has not been modified.

sensors tester sim
  • The blue header shows which test is performed
  • The yellow signals are those generated by the tester
  • The purple signals are the one generated by your implementation
  • You can add and remove signals at will, they will not interfere with the tests

Tests

The following tests are performed for the Hall sensors:

  • For each sensor, a pulse of a fixed period (n times slower for each new sensor) is generated
  • The hallCount is compared to an internal counter, depending on the HALLSENS_2PULSES_PER_TURN constant
  • When zeroPos goes to '1', the hallCount should be reset

The following tests are performed for the Ranger:

  • A pulse of tbRangerDistanceTarget (1012) * (clockPeriod / 10) will be generated
  • When the signal distancePulse falls, the rangerDistance should be updated with a value of 1011 to 1013

The transcript window gives you details on if tests passed or not:

  • For the hallCount signal, you get Hall count n OK or Hall count n error.
  • For the rangerdistance signal, you get Ultrasound ranger OK or Ultrasound ranger error.
Personal tools
Namespaces
Variants
Actions
Navigation
Modules / Projects
Browse
Toolbox