PRLS Example Software

The examples directory in our embedded software repository contains example code for using the Module Core with most of the PRLS hardware. The available projects are listed below.

Blinky

The blinky project is the standard “hello world” equivalent for embedded systems. It simply flashes an LED to demonstrate that the system is functional.

Hardware requirements

This project requires only the Module Core hardware.

Expected behavior

The onboard LEDs should all flash together at 1Hz, staying on for 0.25 seconds, then off for 0.75 seconds.


Background loops

The background_loops project demonstrates the ability to create fixed-rate background threads using the LoopManager.

Hardware requirements

This project requires only the Module Core hardware.

Expected behavior

The onboard LEDs should flash independently, with LED1 flashing at 1hz, LED2 flashing at 2Hz, and LED3 flashing at 4Hz. Each LED should be on for half the period, then off for the other half.


Switches

The switches project demonstrates the ability to read the state of a switch (i.e., whether or not the switch is pressed).

Hardware requirements

This project uses a hardware switch. Plug the switch into the SW1 port on the TR Expansion according to the hardware guide.

Expected behavior

The board should do nothing until the switch is pressed. Once the switch is pressed, the LEDs should start blinking at 1hz.


Distance sensors

The distance_sensors project demonstrates the ability to read distance data from the sensors provided in the kit.

Hardware requirements

The project uses three distance sensors, attached to ports I2C1, I2C2, and I2C3 on the TR Expansion according to the hardware guide.

Expected behavior

The distance sensor data can be read via the debugger in the distance_[1,2,3] variables. The value should vary between 0.0 and 2.0 meters depending on the distance from the sensor to an obstacle.


Line sensors

The line_sensors project demonstrates the ability to read line sensor data from the sensors provided in the kit.

Hardware requirements

The project uses five line sensors, attached to ports ADC[3-7] on the TR Expansion according to the hardware guide.

Expected behavior

The line sensor data can be read via the debugger by dereferencing the adc[3-7]_ptr variables. The value should vary between 0 and 4096 depending on the surface at which the sensor is looking.


Audio input

The audio_input project demonstrates the ability to capture audio signals from the microphone provided in the kit.

Hardware requirements

The project uses a microphone attached to the ADC1 port on the TR Expansion according to the hardware guide.

Expected behavior

The audio data will be captured in a circular series of buffers, which can be analyzed in the foreground loop via a debugger. m_processing_buffer->buffer will contain a 4096-length array of ADC data captured at 44.1kHz.


Audio output

The audio_output project demonstrates the ability to generate sound using the speaker provided in the kit.

Hardware requirements

This project uses a speaker + amplifier, with signal and power attached to the ADC2 port and I2C4 ports on the TR Expansion respectively, according to the hardware guide.

Expected behavior

The speaker should produce an audio sine wave at 440Hz (A4 note).


Servos

The servos project demonstrates the ability to command servo positions.

Hardware requirements

This project uses a servo attached to the PWM1 port on the TR Expansion according to the hardware guide. Motor power must also be enabled either by a switch or a jumper.

Expected behavior

The servo should rotate to +90 degrees, then to center, then to -90 degrees, then back to center. This pattern should repeat at 1Hz.


Motor current control

The motor_current_control project demonstrates the ability to apply a current to the motor.

Hardware requirements

This project uses a Motor Submodule attached to the bldc1 port on the TR Expansion according to the hardware guide. Motor power must also be enabled either by a switch or a jumper.

Expected behavior

A constant current will be applied to the motor. This will typically cause the motor to reach a constant maximum velocity, and will feel like a constant torque if the motor is stopped by hand.


Motor position control

The motor_position_control project demonstrates the ability to control the position of the motor using current commands.

Hardware requirements

This project uses a Motor Submodule attached to the bldc1 port on the TR Expansion according to the hardware guide. Motor power must also be enabled either by a switch or a jumper.

Expected behavior

The motor’s position will quickly jump by 90 degrees every 10 seconds. If the motor is manipulated by hand, the motor should exert more torque when it’s farther away from the current desired position.


Motor velocity control

The motor_position_control project demonstrates the ability to control the velocity of the motor using current commands.

Hardware requirements

This project uses a Motor Submodule attached to the bldc1 port on the TR Expansion according to the hardware guide. Motor power must also be enabled either by a switch or a jumper.

Expected behavior

The motor’s velocity will be constant and positive for 10 seconds, then constant and negative for 10 seconds. The motor should exert more torque if you try to slow it down by hand, or less torque if you try to speed it up.


Motor calibration

The motor_calibration project demonstrates one method for calibrating the magnet zero offset for the motors.

Hardware requirements

This project uses two Motor Submodules attached to the bldc1 and bldc2 ports on the TR Expansion according to the hardware guide. Motor power must also be enabled either by a switch or a jumper.

Expected behavior

The motors should twitch in one direction and then the other. An LED will turn on when the calibration procedure is complete. Be sure not to touch the motor while the calibration is in progress, as this will skew the results.

The four sets of calibration data, which can be read in the bldc[1,2]_[fwd,rev]_vel_log variables, should each be saved to a separate file “calibration_[motor serial number]_[fwd,rev].csv” in the utils directory. The utils/analyze_calibration_data.py script can then be used to visualize the calibration data. A plot will be displayed showing the forward and (negated) reverse velocities plotted on top of one another, with the tested offsets on the x-axis. There will typically be one section of the graph with mostly positive velocities, and one with negative velocities. The offset value at the peak of the positive velocities should be chosen as the calibrated offset (see orange line below).