Skip to content

v0.0

Latest
Compare
Choose a tag to compare
@zeke2856 zeke2856 released this 25 Mar 00:14
7cc8db5

RB-CODE-PROTOTYPE-1 release v1.0

Visualization and Simulation

Visualization

The window will show what block servo states, lock servo states, and pixel states.
The sides the actuators are on can also be specified. The block actuators can either be on the 'top' of the 'bottom', top is the default. The lock actuators can either be on the 'left' or the 'right', right being the default.

Actuator Key

Row Actuator

A row actuator is red when it is in the 'locked' state and is green when it is in the 'unlocked' state.

Column Actuator

A column actuator's position is indicated by the location of the little green square within the actuator block. If the square is on the left side of the grey rectangle, the actuator is in the 'subtract' state. If the square is in the middle of the grey rectangle, the actuator is in the 'middle' state. If the square is on the right side of the grey rectangle, the actuator is in the 'add' state.

Visualization Window

Simulation

The Visualization can have a Simulation Enabled. This makes the actuator inputs affect the pixel states in the appropriate way. This allows for debugging of new animations and will help with debugging the physical display.

Enabled Layers

Image Layer

  1. An image is pulled randomly from a folder on the pi.
  2. The image is simplified to grayscale
  3. Rescaled to the native resolution of the display
  4. The colors are simplified using kmeans clustering to only use a specified number of colors.

4 Color Image

Digital Clock Layer

  1. If running, reserves a color for the clock text. This allows for easy differentiation of the clock from the image.
  2. The time is pulled from the internet.
  3. The time is changed into a low-resolution font
  4. The Digital Clock layer is superimposed over the image layer.

3 Color Image and 1 Color Digital Clock Face

Animation

An animation is a series of actuation steps that would change the display from displaying one frame to another.

This simplest form of this would be actuating one pixel at a time. Repeatedly Unlocking one row, actuating a column, and re-Locking that same row. This would be a very time-intensive process.

The faster animation uses fewer actuation cycles. So the goal of any animation is to minimize the number of actuation cycles and maximize the step toward the desired result with each actuation.

Implementing some form of Djikstra's would be ideal if that were the only parameter we cared about. The computation required to generate a fast animation is too great.
Getting the move order for the fastest transition is no simple task. Most algorithms I have thought of (Brute Force and Djikstra's) that get these fast transitions are extremely computationally expensive. This is an interesting problem that I look forward to spending more time on later. For the first iteration of the display, I have implemented a relatively simple animation style that is relatively quick.

First Animation Style

  1. The row with the smallest delta between its pixels' cumulative current and desired values is chosen.
  2. The changes to get that row to its final position are generated.
  3. If that change would bring down the calculated delta of any other rows, those rows are also unlocked.

Pros

  • The Display is mesmerizing while running through this algorithm.
  • Transitions with few unique row shifts are well optimized

Cons

  • Transitions with many unique row shifts are poorly optimized.