top of page

Star Tours Model Ride Vehicle

Fall 2024

What is Introduction to Droid Building?

The University of Notre Dame offers a droid building course every semester, giving students the chance to design and construct a droid/robot using 3D printing, CAD, motion control systems, electrical circuits, sound systems, lighting systems, sensors, various communication protocols (serial, I2C, and Bluetooth), and Arduino programming. The project was completed with my partner, Luke Guenther.

 


The final demonstration at the end of the semester consisted of:

​

  • A build quality review

  • A manual driving course showing the fluidity of the ramping motor control

  • implemented for the PS3 controller

  • An automatic course using a color sensor

  • 3 unique ~90 second automated routines that stay within a 5x5 foot square, showing synchronization across motor control, lighting, sound, the servo, and the display
     

​​

Screenshot 2024-12-24 at 10.17.13 PM.png

Creating the Concept

As part of the final demonstration rubric, all droids must have a functional purpose in the universe they inhabit. All droid building teams were given a rectangular wooden base to get started with. This immediately narrowed our design choices. We also were aware of the need to utilize speakers, lights, a small server motor, and an OLED display.
​
We thought of many ideas, but eventually settled on basing our droid on the Disney theme park attraction, Star Tours - The Adventures Continue.
​
My passion for this ride coupled with how well it could fit the requirements made it a great choice.

ST3.jpeg
ST4.webp
STNew.webp
ST1.jpg

The nature of Star Tours fit the requirements for routines extremely well, as the ride itself is already segmented into 3 distinct ~90 second chunks:

Act I -  Takeoff/Getting Caught/Escaping

Act II - Planet 1/Hologram Message

Act III - Planet 2/Escaping Back to Safety

Possibilities.jpg

The Full Build Process

(More In-Depth Information Further Down)

Building the Chasis

The first step in our build was to mount two precision planetary gear motors to the rear of the droid and a central omni wheel to the front.

IMG20240909184628-min.jpg
IMG20240909184637-min.jpg

Creating Housings for the Battery and Main Power Switch

The placement of all components beyond the chassis wheels/motors would be entirely up to us. Since the battery would be the heaviest component of the entire droid, we decided to place it in a central location, with the power switch nearby.

We also knew not all of the base electrical components would be able to fit on one level, so we would need to leave room along the sides to mount supports for the second level/shell.

Most parts were made in Fusion 360 and 3D printed in the Engineering Innovation Hub (a tinker space in the main engineering building).

IMG20240920151726-min.jpg
IMG20240920155337-min.jpg
IMG20240912134916-min.jpg

These first two components taught us what tolerances to use for future parts with the 3D printers available in the Engineering Innovation Hub.

Programming Manual Motor Control

Our first function allowed the droid to be driven around using a PS3 controller.

A SABER 2X12 Motor Controller was used, which had an Ardunio library that simplified movements to the following:

To adjust turning speed - ST->turn(currentTurn);
To adjust speed forward/back - ST->drive(currentSpeed);

This was our first experience using millis() timers to control how often our function would be called. Every 100ms, the drive and turn speeds would be updated based on the changes in the X and Y axes of the left joystick.

However, it would not be a good idea to instantly jolt the motor speed to its maximum amount, so ramping logic was used. Each time the function gets called it would only increment the speed by a specified ramp step and would stop increasing when the target speed is reached.

IMG20241010202531-min.jpg

Programming Automated Motor Control

Another requirement was that our droid navigates a colored path using a color sensor mounted on its front.

Blue - Go Forward
Red - Need to Turn Left
Green - Need to Turn Right

The Color Sensor (and multiple future components) rely on 5V so a Drok Voltage Regulator was used to step down our 12V battery to 4.9V
 

Screenshot 2024-12-25 at 1.28.25 AM.png
Screenshot 2024-12-25 at 1.27.46 AM.png

The autoMode function was called by pressing the triangle button on the PS3 controller. This would change state variables in our main loop so that the manual movement function was no longer called. The function itself was very simple to the manual movement function except the target turn and drive speeds were hard-coded.
 

Sound Design and Ambient Sound Implementation

15 sound files were custom-made mostly using the audio loop from the maintenance bay section of the Star Tours ride queue. This included some great banter between R2-D2 (who would be mounted to the model soon) and C-3PO (implied to be driving the model).

To make it appear as though the model is an actual spaceship, I added in an ambient droning X-Wing engine sound to the background. This specific ship sound was ideal because there was very little variation in its volume and pitch. By playing two sound files, each containing the same ambient engine noise in the background, the cut between audio files would be much less noticeable.

I also created a sound file exclusively for the ship startup sequence (the first thing that happens when you flip the power switch on).
 

Ambient Sound Files

Startup

00:00 / 00:35

1-5

00:00 / 00:20
00:00 / 00:20
00:00 / 00:20
00:00 / 00:45
00:00 / 00:30

6-10

00:00 / 00:30
00:00 / 00:25
00:00 / 00:40
00:00 / 00:40
00:00 / 00:30

11-15

00:00 / 00:40
00:00 / 00:45
00:00 / 00:45
00:00 / 01:00
00:00 / 00:45

After the startup sequence, one of the 15 possible sound files would be randomly triggered using a Robertsonics MP3 Triggerboard with an SD card holding the audio files. The trigger board connected to a Kinter MA170+ Amplifier which then went out in stereo to 2 speakers.

Screenshot 2024-12-25 at 2.35.27 AM-min.png
Screenshot 2024-12-25 at 2.37.14 AM-min.png
IMG20241105150750-min.jpg

An array was initialized at the beginning of the Arduino file that had the length of each sound in milliseconds. This way the function called to play ambient sounds knew how long to set its millis() timer for before switching to another audio file.

Modeling and Printing the Supports

This step required the most forward-thinking and anticipation of our future obstacles than any other step before this.

The clearance needed for the battery to be able to be picked up and out of its carriage became the location for our second floor's platform. And in order to meet the creative intent of our spaceship design, the width of the supports would need to reach just outside of the rear wheel's width. These 2 limitations determined the ratios for the rest of our droid's dimensions. The extra height and width meant the length would need to extend considerably past the chassis in both directions.

This would prove difficult for 2 reasons:

  1. We did not have access to 3D printers that could print big enough extension/supports

  2. There would be an incline we would need to clear on the final demonstration course

​​

The Solution: 

Split the extensions and supports into 2 separate components​

cad2-min.png
Screenshot 2024-12-25 at 3.10.08 AM-min.png

We also knew we would be mounting a linear actuator for R2-D2 to the front left support, so we added an extra flat edge on the front left support. Additionally, we added holes for LEDs in the front supports.

Screenshot 2024-12-25 at 3.09.47 AM-min.png

All together, the supports create an accurate silhouette of the ride vehicle's shape

IMG20241030162238-min.jpg

Adding LEDs and NeoPixels

Part of the prompt was to add a component separate from what was required by everyone. We chose to use 2 NeoPixel strips along the inside of the droid's shell. We split off one of the Arduino's PWM ports to both strips and made multiple functions which utilize millis() timing logic to create different patterns.

While the droid is in ambient mode, the strips pulsate as if they are thrusters, slowly switching between a more yellowish look to a bluer tone.

When in auto mode, the strips simply show whatever color the color sensor detects, and creates rainbow effect when successfully completing the course.

For the routines, multiple effects were used:

  • ​A startup sequence

  • Red fire

  • Jumping to lightspeed

  • Caught in a dogfight with tie fighters

  • Caught in a dogfight with Boba Fett

  • Now boarding lights

  • Podracing over sand

  • Strobe light crashing effect

  • Green pulses for Yoda

  • Red for Darth Vader

​

The LEDs were eventually velcroed to the inner side of the shells.

Screenshot 2024-12-25 at 3.58.58 AM.png

Typical LEDs were used for all other lighting, including 10 LEDs for the headlights, 2 for R2-D2, and 2 for the rear thrusters. The rear thrusters had a special acrylic pane encasing them, which dissipated light evenly. All the LEDs were controlled with an Adafruit 24-channel PWM driver.

​

The R2-D2 LEDs had a special ambient function that would make them appear to be blinking randomly, as if processing data or showing R2-D2 is speaking.

​

The rear thruster LEDs had a function that made them appear to pulsate.

Screenshot 2024-12-25 at 4.02.10 AM-min.png
Screenshot 2024-12-25 at 4.05.47 AM-min.png
Screenshot 2024-12-25 at 4.03.43 AM-min.png
Night Time Footage of Lighting

Getting R2-D2 and the TFT Display Working

Using a linear actuator powered by an MG90S servo, we attached velcroed and tied down R2-D2 to one end (I hollowed out a model of R2-D2 I found online and made holes for the LEDs). Once R2-D2 was attached, I began testing it with the main code, but there was a problem. Because I was asking the Arduino to do so much each loop (even with timers minimizing how many times a function is called), R2-D2 would begin to jitter each time I told him to move to a position. The fix was to detach the servo from the PWM port and reattach it whenever I stopped/started moving R2-D2. While the finished problem wasn't so smooth, I believe that was simply a limitation of the Arduino, and in the end, R2-D2's movements still looked relatively nice.

In ambient mode, R2-D2 moves up and down for a random amount of time at randomly chosen intervals. For the routines, we made a function that when called would move R2-D2 for only 2 seconds and no more. This was helpful for timing his movements with audio queues.

Screenshot 2024-12-25 at 3.13.31 AM-min.png

The OLED TFT display from Adafruit was able to display images using large binary arrays.
​
In ambient mode, the display simply shuffles through possible images every 10 seconds.
​
In the routines, the display was used to show a random rebel spy (me, Luke, or my brother) as well as these other images relating to the story at that moment:

  • The Star Tours logo

  • R2-D2

  • C-3PO

  • Darth Vader

  • An animation for jumping to lightspeed

  • Tatooine

  • A podracer

  • Yoda

  • The Death Star

  • Boba Fett

  • Boba Fett's Ship (Slave I)

  • Tie Fighter

  • A trophy

  • A "Now Boarding" screen

  • An explosion
    ​

Screenshot 2024-12-25 at 4.31.39 AM-min.png
Screenshot 2024-12-25 at 4.31.30 AM-min.png
Screenshot 2024-12-25 at 4.30.35 AM-min.png

Creating and Painting Cosmetic Pieces and Shells

The shell is made entirely out of foam-core board with 3D printed pieces velcroed on top. To give it a red, glossy look, all of it was first spray painted in red Rustoleum spray paint. R2D2 was spray painted with white then hand painted.

Then, all detail work beyond the base red was done with glossy acrylic paints and using paint brushes along with some paint markers.

IMG20241129140853-min.jpg
IMG_5618.HEIC
IMG_5621-min_edited.png
IMG_5622.HEIC
IMG20241202153904-min.jpg

The Routines

All 3 routines have the same format for their functions. I split up the controllers for the routines into a ride and show controller. The ride controller is only affecting the droid's movements while the show controller is controlling the lights, sound, R2-D2, etc.

All 3 Routines with Movement
bottom of page