How to build a wireless controller

Digital Systems Teaching and Research (DSTR) Robot Controller Tutorial 

Students at Texas A&M University have developed the DSTR Robot – a small form factor robotic platform – in the University’s Mobile Integrated Solutions Laboratory. In a little over a year, DSTR has caught the attention of NASA scientists as a potential vehicle for sample collection on the moon. They are working with the Texas A&M team to develop a controllable arm with a rotating scoop that will allow the DSTR to collect dirt and sand. The little robot captured their interest based on its small mass, small form factor and its ability to retrieve samples further from the lander. 

The Texas A&M team built their own unique controller to use with the DSTR.  It was conceptualized when they started incorporating first-person view (FPV) into the DSTR. They found that when they were wearing FPV goggles on their face, strictly using the phone application did not give the tactile feedback that would allow them to best control the robot. The controller currently sends data using User Datagram Protocol (UDP) packets over a Wi-Fi connection to a specified port. The team transmits control commands based on inputs from the joystick.

Below is a step-by-step tutorial from the Texas A&M team to build the same type of controller used for the DSTR robot. Other iterations of the controller could transmit control commands from the tilt of the gyroscope, use the buttons to change to a different mode, the sky’s the limit! Build your own controller and tell us how you use it either in your class or for a fun side project.


Things you need to know before we get started:

The control communications for the DSTR started with Bluetooth® low energy using the SimpleLink™ CC2650 SensorTag kit. Today, most of the DSTRs we’ve built are controlled over Wi-Fi® connections utilizing UDP packets to send commands for the motors from a controller to the robot. In either case, to control a motor like this there are two important details that you need to know:

  • How much power to apply
  • Which direction you want to the motor to turn.

For this reason, the data being transferred was put into packets of four separate bytes, where two bytes are used to characterize the movement of each motor.

The DSTR controls motors through the use of Pulse Width Modulation (PWM) signals sent to a power driver board. By increasing the duty cycle of a PWM signal correctly connected to inputs on the power driver board, the voltage across the respective motor is increased. For the brushed DC motors that we used, a higher voltage means higher Rotations per Minute (RPM); through translation to a wheel, this means higher speed.

How to control the duty cycle of this PWM signal using one of the two bytes being sent per motor: One byte contains eight bits, which in an unsigned binary system has a total of 256 combinations ranging in value from 0 to 255. So for each motor, an 8-bit unsigned binary value from 0 to 255 is used to communicate to the DSTR. Unfortunately for us, the original programming on the SensorTag used a system in which 255 represented a 0% duty cycle, and a 0 represented a 100% duty cycle. Since we still use the phone application with backwards compatibility amongst DSTRs, this convention has been brought along to the next generation of our DSTR controllers.

How to communicate which direction we want the motors to turn: Normally, directions can be sent as binary values, either a 0 or 1, allowing a simple comparison to determine the required motor direction. However, in order to add even more learning material to the DSTR environment, the direction bytes are sent as hex values. Hexadecimal values are each 4 bits long, and count up from 0-9 and then from A-F (where A has a decimal value of 10 and F has a decimal value of 15). A hexadecimal value of 0xAA is used to represent one direction while a hexadecimal value of 0xBB represents the opposite direction. As long as you understand what you are sending, and adjust accordingly on your receiving side, this communication method can be modified to your needs.

How to determine the order to send these bytes: This is important, because when you try to interpret the packet on the receiver side you need to know which byte should be compared against 0xAA and 0xBB for direction and which byte is a value representing the motor speed. For our application we used the order as follows: Direction, Speed, Direction, Speed. But wait, which direction is for which speed? That’s where the fun comes in!

Debugging is a personal favorite of our team. Try the tutorial out, figure out if your system acts odd, try to work out what could cause that behavior, and then figure out a solution using hardware (re-wiring) or software (switching bytes).


Let’s get started:

Hardware Components

Software Apps & Online Services

Build the wireless controller

Here are the four boards that will make up the stack for the controller. Going from left to right, we have: the Fuel Tank MKII Battery BoosterPack Plug-In Module, the MSP432P401R LaunchPad Development Kit, the CC3100 wireless network processor BoosterPack plug in module, and the Educational BoosterPack MKII. 

Take the MSP432 LaunchPad kit and the CC3100 BoosterPack module and make sure that they are both oriented in the same direction. You should be able to determine this by looking at the TI logos, or by checking that the top left pin on the connector is in fact 3V3. 

You will then stack the CC3100 BoosterPack module on top of the MSP432 LaunchPad kit and it should look like this. (NOTE: It’s important when stacking these boards that you ensure that the pins are lined up perfectly and that there’s no offset. It is VERY easy to accidentally connect power to ground and fry your microcontroller).

Next, taking the stack you just created, follow the same steps with ensuring you have the boards lined up correctly with the Battery BoosterPack, and add it to the bottom. (NOTE: make sure the switch on the Battery BoosterPack is in the “DISCONNECT” position anytime you’re putting it on or taking it off the stack)

Your stack should now look like this.

The last board that needs to be added to the stack is the Educational MKII BoosterPack module. Following the same steps above, add the Educational MKII BoosterPack module to the top of the stack.

This is what your final stack should look like.


Program the remote controller


Here is a flowchart of the sketch that we will be uploading onto the controller.


  • The normal rectangles represent operations
  • The double lined rectangles represent functions
  • The diamonds represent decisions
  • The arrows represent the order of the operations

Sketches in Energia all have the same basic format: you have a setup function and a loop function. Everything before and inside the setup function will only run once. This can be seen in the flowchart with the last box reading, “Begin listening on local port.” Everything after that box is inside the loop function, executed in top to bottom order before looping on and on forever.  This is why there’s an arrow feeding back into the box that reads, “Read joystick value and re-map range.” 


Source Code

Download the source code found here:

  DSTR Joystick

Once you have the program open in Energia, connect the microUSB connector from your laptop or desktop to the microUSB port on the LaunchPad kit.

Go to Tools > Board and make sure the board selected is the “LaunchPad w/ MSP432 EMT (48MHz).” If you don’t see this as one of the options on the dropdown menu, select Board Manager and install the package if necessary.

Once you check that, you can compile the sketch by clicking the checkmark at the top left in Energia and if it compiles successfully, upload the program to your LaunchPad kit by clicking the arrow located to the right of the checkmark.

Once Energia tells you that the program has been uploaded successfully, the DSTR logo will start being drawn to the LCD on the Educational MKII BoosterPack. This validates that the program is working properly, and should begin trying to connect to your robot. (*NOTE: Make sure when you’re writing the code on the robot side that the Wi-Fi name and password match exactly. Case does matter!) 


Optional: print your own enclosure!

If you have access to a 3D printer, you can print your own enclosure like the one shown below!  We’ve included the STL files. It will print in two pieces (top and bottom) so that you can remove the stack as necessary.

Download casing file here: 


Congrats! You’ve built your very own wireless controller. Have any questions? Comment in the below and we’ll be sure to answer them.

In the meantime, be sure to check out these additional resources:


Meet the DSTR Team 

Alexis Crandall - Program Coordinator (Technical support & controller design)

Colby Ryan - Lead Technical Support (Embedded Intelligence Design for original SensorTag version of DSTR)

Herbert Baumgartner – Designer (Designed the original mechanical structure and continuing development)

Vince Rodriguez – Designer (Designed the DSTR phone app that is now on the Apple App Store and the Google Play Store; designed the embedded intelligence for the current version of DSTR that uses a CC3200 LaunchPad)

Salvador Echeveste – Designer (Designed the enclosure for the controller; continued to make mechanical improvements to the robot for the NASA version)