Firefly Eindhoven - Light Design

Introduction

In order to create a drone show that involves lighting effects, one of the requirements is a program or set of scripts that is able to create a sequence of lighting effects. The effects should be configurable in duration, speed and colour, just to name a few parameters. To accomplish this, a set of Matlab functions has been developed which allows one to generate a trajectory of LED data which can then be read and displayed by the LEDs on the drone.

This report is written for those who want to familiarize themselves with the existing set of functions, build new ones, or get acquainted with the steps necessary to generate a trajectory. All of the aforementioned will be discussed in detail in the sections below.

The files that are discussed in this report are available for review in two ways:

• As an attachment to an Adobe PDF version of this report;
• Through Github: find the files in the Visualization branch of the Firefly team repository.

Process Flow

In this section, the general process flow that is used to generate an LED trajectory is described. Consider the flowchart in [fig:general-process] below:

The goal of the flowchart is to provide a general overview of which process steps are needed to design a trajectory, and which resources are required at each step. For example, information about the music and stage are necessary to start designing an LED trajectory. In the following sections, further elaboration is provided on each relevant process step.

LED Effects

In this section, the available set of LED effects is provided and a description is given for each of the effects. The LED effects are written as Matlab functions that take a set of input parameters and output a (2D) cell of LED data. The goal was to create flexible and general effects that can be used for a wide variety of situations and creative ideas.

There are some general function arguments that appear in almost every effect. These are listed and described below:

• f (system frequency) - the frequency at which the effects are displayed
• N (amount of LEDs) - the amount of LEDs on the drone
• t (time) - The time duration of the effect (in seconds)
• HSV (color triplet) - defines the HSV colour triplet/vector ([math]\displaystyle{ \mathbb{R}^3 }[/math]) which is shown during the effect
• offset (start offset) - An offset, specified in a number of LEDs that shifts the whole effect sequence [math]\displaystyle{ n }[/math] LED positions to the right for its full duration.

List of LED effects

Currently, the following effects (functions) are available:

• Colorwipe: colorwipe(f,N,t,hsv,offset)

  • Description: Fills an initially empty LED strip one-by-one with a specified colour and within a provided amount of time. The filling sequence runs from left to right and can be offset (such that it starts at any point between the first and last LED).

  • Additional parameters: None.

  • Additional comments: None.

• Comet: comet(f, N, t, t_lap, lentrail, hsv, offset)

  • Description: A bright source travels around the LED strip, leaving behind a fading trail of LEDs. The colour and speed of the source and length of the trail can be specified.

  • Additional parameters: t_lap specifies the time required for the source to complete one full lap. lentrail specifies the length of the trail of the comet.

  • Additional comments: None.

• FadeHSV: fadehsv(f, N, t, d_in, d_out, hsv)

  • Description: A constant colour is uniformly displayed across the whole LED strip for a specified amount of time. The effects allows for fade-in and fade-out to black.

  • Additional parameters: d_in and d_out specify the fade-in and fade-out duration, respectively.

  • Additional comments: Also see 'MultifadeHSV'.

• MultifadeHSV: multifadehsv(f, N, t, d_in, d_out, t_cf, d_cf, hsv1, hsv2)

  • Description: This effect allows fading between two different colours with an optional fade-in and fade-out effect at the start. It can be considered an 'advanced' version of fadeHSV (see above). An infinite number of these sequences can be concatenated to fade between more than two colours.

  • Additional parameters: d_in and d_out specify the fade-in and fade-out duration, t_cf species the time at which the colour transition (fade) takes place and d_cf specifies the duration of the colour transition.

  • Additional comments: Also see 'FadeHSV'.

• Rainbow: rainbow(f, N, t, laps, n_rb, V, d_in, d_out)

  • Description: A full range of hues is displayed across the full length of the LED strip and this spectrum also moves around the strip (left to right).

  • Additional parameters: laps specifies the amount of laps to complete within the specified time t. n_rb specifies the amount of rainbows on the strip at any given time. d_in and d_out specify the fade-in and fade-out time (from/to black) if necessary and are otherwise set to zero.

  • Additional comments: Also available in a static version (no movement) - see Rainbow_static. Also note: sv [math]\displaystyle{ \in\mathbb{R}^2 }[/math].

• Rainbow_static: rainbow_static(f, N, t, n_rb, sv)

  • Description: A full range of hues is displayed across the full length of the LED strip. Same as rainbow, but without movement.

  • Additional parameters: n_rb specifies the amount of hue spectrums (rainbows) that are displayed.

  • Additional comments: Also available in a moving version - see Rainbow.

• Sparkle: sparkle(f, N, t, V, colour, density, dimspeed)

  • Description: Sparkles of random colour (hue value) are randomly displayed across the LEDs. These sources than fade away at a preset rate, creating a sparkling/glitter effect.

  • Additional parameters: colour is a boolean value that specifies whether the sparkles should be (randomly) coloured or not (white sparkles). density is a fractional value that determines the 'spawn rate' of sparkles on the LED strip. dimspeed is a fractional value that defines how much the LEDs dim with respect to their previous state.

  • Additional comments: The function attempts to generate new sparkles at every iteration step, which means that the density parameter should be low for normal use (order of 0.02 - 0.10).

• Wave: wave(f,N,t,hsv,dimfactor,offset)

  • Description: A source LED flows both left and right (like a wave) while the source fades away as it proceeds. It also leaves a trail which fades away when its distance from the source LED increases.

  • Additional parameters: the v value in parameter hsv specifies the initial brightness value of the source. dimfactor influences the length of the wave 'trail' and should be rather high (0.8-0.95, approximately) for regular use since it is used in every iteration.

  • Additional comments: This effect has not been optimized for LED strips with an uneven amount of LEDs (the effect is symmetric!).

Additional effects will be added upon request. Any bugs should be reported to Willem. You can contact him through TU/e e-mail (Pennings, W.J.).

Known bugs and points of improvement

• comet.m starts with a trail but it probably looks nicer if it starts without a trail.

Trajectory concatenation and conversion

After the individual trajectory sections have been defined, they have to be combined in order to form a full trajectory. Additionally, the full trajectory data cell should be converted to a format that can be interpreted by the quadcopter itself. These steps will be outlined in this section.

Trajectory concatenation

All of the relevant steps in this section are performed in the trajectory.m file. At the top of this file, general system parameters such as the frequency and amount of LEDs are specified, since they are (and should) be equal for all effects. Next, the trajectory parts are generated and immediately concatened using Matlab's vertcat command. The resulting matrix has [math]\displaystyle{ m }[/math] columns - equal to the amount of LEDs on the strip - and [math]\displaystyle{ n }[/math] rows - equal to the frequency multiplied by the sum of all individual effect durations (plus one). Refer to the flowchart in [fig:concatenation-conversion] below for the full process specification.

Trajectory conversion

The data that is output after concatenation is in Matlab's cell format, which means that each element of the 2D cell contains an HSV triplet vector (three values). This format does not interface well with the drone, so it has to be converted. Additionally, colours have to be converted to RGB colour space. All this is done in the following sequence:

1. Each of the HSV triplets in the 2D cell are converted to RGB triplets using a conversion function;
2. The 2D cell data object is converted to a 'regular' 3D matrix. The triplets have been expanded into the added matrix dimension.
3. The resulting data is saved to a mat-file which contains the colour data as well as a time vector (which is coupled to the colour data in Simulink).

In Figure [fig:concatenation-conversion] which is displayed below, the full concatenation & conversion process specification is shown.

Trajectory visualization

A Matlab script was created that enables a user to visualize the generated LED effects in real time. The Matlab script is called visualizeLEDs.m and its features and limitations are discussed below.

The script requires two inputs: An LED data file, which by default is called LEDdata.mat and a song file, which by default is called song.mp3. The LED data file should require no modifications whatsoever as the visualization script was made to read the format that is generated by trajectory.m, the script that generates the actual LED data.

When running the script, the specified song automatically starts playing and the visualization appears in a plot with a black background. What is displayed are three circles, each filled with a number of LEDs equal to that in the LED data file. The circles represent the LED strips on the physical drone and, in combination with the music, allow for quick trajectory debugging. A snapshot of the visualization in action is shown in [fig:visualization] below.

LED implementation

When the led design is fully defined, the exported MAT file needs to be implemented on the drone itself. To implement this there has been made use of Simulink®. First the initialization script has to run in order to load the data file in the correct format, timeseries object, to the workspace. After that, the Simulink® file needs to be opened and build, in order to be uploaded to the drone itself.

The size of the initial data file that is exported from the trajectory generation script is relatively big. Depending on the frequency, length and number of LEDs that are used, the dimensions will be, (time in seconds * frequency) x number of LEDs x 3 (storing r, g, b values). The first led design had a frequency of 10Hz, the dimensions were 1258 x 89 x 3. During the process it was clear that this kind of dimensions were too large to upload to the drones limited memory. To compensate for the limited memory the frequency of the trajectory has been limited to 5Hz, which had still an acceptable end result on the drone.

Furthermore, inside the initialization script the data needed to be compressed more, this is done by removing unnecessary lines. A script has been made that removes all lines which are the same as the previous line. Because Simulink is looking at the closest timestamp that is available, this modification will not affect the end result on the drone itself. As a result of this, the dimensions became 397 x 89 x 3, which is small enough to upload to the drone’s memory.

Inside the Simulink there has been made use of the From workspace block which is giving the corresponding 89 x 3 signal at the current timestamp on the drone, which starts counting on the moment the drone has been turned on. This is inputted in a MATLAB script inside the Simulink file which is converting the 89 x 3 signal to the appropriate Uint_8 format that is needed for controlling the LEDs. This function is connected to the led control block of Avular which will send the appropriate signals to the led strip. Inside the user manual of Avular is shown how to actually upload the code to the drone and which software there is needed to do so.

LED carpet

After showing a successful show with one drone at the TMC event on April 2018 and talking to multiple potential partners which were interested in the show, it became clear that the current drone show was too limited. By only combining music with 3 drones flying, which only have 1 single led strip, had not the wow factor that was needed to be able to show it at a big event such as Glow Eindhoven. In order to improve the visual effect of the show, the concept of a LED carpet was introduced. It illuminates the floor over which the drones fly. Development is still in an early phase, and thus not much documentation or information is available on it.

Layout

The current idea of the LED carpet is to create a grid by laying out LED strips over a stage in parallel. A spacing of 30 cm between LEDs in both horizontal and vertical direction was determined to be sufficient for a first concept; this would require a total of 600 LEDs for a stage that measures 9 x 6 m. However, since most adressable LED strips are not available with 30 cm spacing but instead come with a maximum spacing of 3 cm between LEDs, this would increase the total number of LEDs to 4500 ([math]\displaystyle{ 9\cdot 6\cdot 30 }[/math]). This is rather much and introduces several scaling problems (power electronics, processing power). Custom parts are therefore to be considered, although this may result in relatively high system cost.

Physical realization

Several realization options are currently being considered:

• Fitting LEDs to tiles of size 1 x 1 m, which can be attached to one another to create a LED carpet that is very flexible in terms of size and also easy to scale up;
• Fitting LEDs to sheets/carpet that can be rolled up for storage. A typical dimension would be 5 x 1 m. This concept is slightly less flexible than the previous because the individual segments are larger, but is also easier to assemble since less interconnections are needed;
• Creating a structure of two parallel beams (placed a few meter apart) between which LED strips can be placed and pre-stressed, such that they are straight and always face up. The advantage to this concept is that no bottom layer is needed, allowing the LED structure to be stored in a very compact way.

For the concept where no dedicated bottom layer is used and LED strips are pre-tensioned, a pre-tensioning device was designed. It can be used to clamp an LED strip at its ends. This device can then be attached to some rigid structure, placed at both ends of the stage. The image below provides a conceptual drawing of the LED strip holder with some relevant dimensions.

These parts can be manufactured using a laser cutter, which is relatively inexpensive when compared to 3D printing. For a full-scale LED carpet, more holders are needed, which decreases the price per unit (because of fixed startup costs and minimal raw material dimensions).

For hardware feasibility tests are done to confirm the hardware is able to handle 4000 leds at a reasonable frequency. Next to that there has been experimented with controlling the led carpet over UART from a PC. The first results are positive to go further with the current setup.

Materials

A list of materials that is considered necessary to manufacture an LED carpet is specified below:

• LEDs: LED strips are the most straightforward choice. Several types of adressable RGB strips are available, WS2812b being the most common type; an alternative is the APA102 LED strip.
• Processing unit: Arduino microprocessors are suitable for simple applications with few LEDs; for larger applications as envisaged above (600+ LEDs), devices such as the Teensy or Raspberry Pi are more suitable.
• Structural parts: Depending on the choice of concept the following parts are required:
  • Bottom layer material if either tiles or rollable sheets are to be used;
  • Beams and prestressing components to which the LED strips can be attached if the third option is to be considered.
• Power electronics: A sufficiently large low-voltage (5V/12V) power supply, including wires, fuses, switches, relays and other (safety) equipment.