Using the TI LaunchPad from your KoP

Technical Control System
1

As many readers here at CD may know, Texas Instruments is a diamond level supplier to FIRST, but you haven’t seen our name in your KoP before. TI works hard in the background to supply the silicon that goes into the control systems components, but we wanted to put our technology directly into your hands this year. To this end, we’ve included a new MSP430 LaunchPad in every single KoP.

Now, you can go ahead and use it for whatever you like (plenty of examples and information avaliable here: http://www.ti.com/ww/en/launchpad/launchpad.html), but our flagship purpose for this year is as a custom operator interface for your driver’s station. A solution was developed by software engineers at TI so that all you have to do is flash the board, and it will show up as a USB HID Gamepad, ready for input. This has been fully tested and vetted by our best guys, so you know it won’t stop working in the middle of a match.

We also worked closely with NI to make sure that it’s as easy as possible for you to get started, and get some cool new features out of it. You may have already noticed the “Game Pad Tool” in your NI update. This is a dedicated application to make programming easy; just select your pinout and hit program, no additional downloads needed.

Our engineers also worked with NI to add digital outputs to the HID specification available to you via the driver station. You can now use the LaunchPad to set digital indicators or anything else you can think of, straight from the driver’s station using new WPILib API calls.

Since there is a limit to the number of pins available, we worked out three configurations that should have you guys covered:

  1. 8x analog, 11 digital inputs, and 11 digital outputs,
  2. 8x analog, 16 digital inputs, and 6 digital outputs,
  3. 8x analog, 20 digital inputs, and 2 digital outputs

Feel free to let us know if you want something else though.

For more information on the solution, with some fun examples of what you can do with a custom operator’s interface, check out our wiki page here: http://processors.wiki.ti.com/index.php/MSP430_LaunchPad_Operator_Interface_for_FIRST_Robotics_Competition

In addition to our activity here on CD, we’ve also set up a dedicated FRC support hotline that will let you contact TI engineers directly at [email protected]. Everyone on this list is not only a TI engineer, but also a dedicated FRC mentor, so try not to send us too many emails during week 6 :slight_smile:

We have a lot of other ideas for using the LaunchPad on your robots as well (an LED controller is at the top of our list) so keep an eye out for more examples to come!

2

FIRST off, thank you!

We on 2073 love to do custom controls, this will give us a FANTASTIC option to add to our bag if tricks.

Is there a way we can get a second, or even third, board? We often build multiple identical robots, and having two, or more, identical drivers stations would be an added bonus.

3

Here at FRC 116, we implement custom OI controls for each of our robots over the past several years. We find that it’s more effective to have a dedicated switch labeled “Deploy” than it is to try to remember which button on a joystick is mapped to the same feature. So, during the beta test cycle, the ability to create outputs ala LEDs was one of the many questions that got submitted.

Thank you for working with NI to make this happen.

Mike

4

The easiest option would probably be to get extras from the TI e-store ( https://store.ti.com/msp-exp430f5529lp.aspx ) since we have free shipping. Since the LaunchPad isn’t a dedicated FIRST part, you can rest assured that we will not run out of stock. If you do have problems purchasing extras (we know how hard purchasing can be from a school account), feel free to drop me a PM or email our support list and we’ll see what we can do.

5

We’ve already got a couple more on order from the TI store. We’re looking forward to getting some cool controls whipped up as soon as the build team figures out what we’re controlling.

6

2 more ordered last night. 1 for our second DS, and one for … well… me to play with.
Uhhhh, I mean, to experiment with so that we can get even better at utilizing it’s possibilities. Yeah, that’s my story and I’m sticking to it.

7

Awesome to hear you guys are jumping right in!

I know it’s robot season, so there isn’t much time left over for personal tinkering, but the community over at 43ohis a really great resource for people starting out. You might want to check out their projectsforum for some ideas on what the board can do.

8

Personal time during build season? What’s that? ;-). But, I will cruise over to the link and have a look. In the mean time, I’m trying to find info on the HID output features. Not much available in the docs so far. So, it looks like it’s going to be interesting to noodle it out.

How can you tell the pioneers? They’re the ones with the arrows in their backs. :yikes:

9

What additional information are you looking for?

Currently, the output is just driving a pin high (3.3V) or low from the MSP430. Essentially, you can set it in WPILib, and it will get transferred to the HID device on the following USB poll cycle (every 20ms). I’ll get my software cohort to elaborate a bit more for you guys on this.

The max a single pin can source is 10mA, and the device total is 100mA.

When I made the example panels on the wiki, I just used the indicator pins output to directly drive the LEDs. No problems so far.

10

On the robot side I have only had a chance to work with the LabVIEW WPILib API, but I assume it is similar in both Java and C++. The idea is you pass a boolean array to WPI_JoystickSetOutput.vi which is sent to the LaunchPad, which then sets/clears the appropriate indicator. See attached from the LabVIEW context help (you can ignore the rumble outputs).

If you load one of the three default firmware images it becomes straight forward to set/clear the indicator outputs using the API, which you can then use to drive an LED or other indicator.

In addition, we are working on the documentation for the source code provided on our github page, beyond what is commented in the code (including setup instructions). So if you want to do something else with the output data outside of what the 3 preconfigured binaries provide, you can.

LabVIEW Output.PNG


LabVIEW Output.PNG

11

Look in the Joystick class, SetOutput and SetOutputs.

12

Thanks! I’ll take a look at that.

13

Thank you TI! As the lead mentor of a team who experienced losing a match in the elimination rounds due to a different product with a similar function flaking out on us, I am very glad to see this change. Having a well-vetted board for custom driver station inputs included in the KOP is something I mentioned for briefly to one of the FIRST personnel at the event and he put it in his notes, and it’s something I mentioned for again in the end-of-season survey.

I’m not sure if others lobbied for this to happen, but I feel like my detailed suggestions to FIRST on the matter were given very serious and detailed consideration, and FIRST and TI acted on those suggestions.

It’s nice to feel as if I’ve influenced positive changes in FIRST on a global scale.

Thank you FIRST and TI!

14

Thanks Bart!

I received my two extra boards yesterday. It was very simple to follow the instructions at http://processors.wiki.ti.com/index.php/MSP430_LaunchPad_Operator_Interface_for_FIRST_Robotics_Competition to get the board configured as a Gamepad.

Once I verified the DS saw it as a controller, I wanted to explore the code behind the magic, maybe even edit it.

I was able to get Energia installed, but now I see that it does not support USB HID devices.

Code Composer Studio looks to be the best alternative. What I would like to know is, it looks like the free use license for use with this model of the LaunchPad has a 16K code size limit. Is this a realistic size for the code we are currently using? Additionally, what folder(s) on the Github contain the example Gamepad projects?

15

Energia support for this is something we tried to push for, and would love to see in the future. It just wasn’t going to happen for this release.

The gamepad code comes out to be around 10K, so it is cutting it close, but it should not be a problem for most modifications.

The root folder is the whole project, the three different options are selected based on build properties in CCS. The important files are the source files in the root, and the files in the USB_config and USB_app folders.

CCS is Eclipse based and needs a workspace set up before importing projects. To set up CCS to work on the project, clone the MSP430-Gamepad repo into your workspace folder. From there you should be able to import and run the code.

I will be posting more detailed documentation soon.

16

Thanks Will.

The priority to modify the three existing options is actually fairly low, at least for this season. The modifications I was considering adding can be easily achieved by simply adding a small arduino to the DS in addition to the LaunchPad.
I was hoping to add the ability to run a fairly long set of addressable LEDs in the DS. By simply jumpering a few of the Digital Indicator lines to the Arduino, we can get all kinds of really nice lighting effects.

I’ll stay on the lookout for more information on how to work with the LaunchPad. Honestly, Energia is a good start, but it really needs to be able to handle working with the LaunchPad as a USB HID device, just as the Teensyduino Plugin does for Arduino and the Teensy board(s).

17

I’m actually working on a way to add LEDs into OI panels elegantly. I wrote an Energia library to use the WS28xx LEDs a few months ago for another project, and it ports into CCS just fine. The technical issue is getting it to exist concurrently with the USB Library. While that’s obviously the dream option at this point, the co-processor solution you brought up will work fine.

The plan now is to have a second LP, with some static animations built in. Then you can either use a back channel serial over USB link to tell it which to run, or the indicator outputs from the first LaunchPad can connect as inputs on the second LP to map as specific animations. The second option would reduce the software complexity from the drivers station, but both can exist at the same time to simplify loading firmware.

Since you’re blazing the trail here, I’d love to hear any feedback you might have.

18

It sounds like you are talking about the exact same thing I was going to try to pull off. I am NOT a coding Guru, but just a decent Hack.

The second option you mentioned above is exactly what we will be doing except the second processor will be an Arduino, cuz I have that working already and know how to make it dance!

19

I set up the LaunchPad using my Mac OS X computer running Windows 8.1 under Parallels. When it tried to update the debugger on the first program attempt, it failed and quit seeing the LaunchPad. I worked with TI to get it fixed and it turns out it’s quite simple, see this post, you can fix it from the command line in your Windows guest OS: http://www.chiefdelphi.com/forums/showthread.php?t=132277&highlight=launchpad

One possible way to prevent it in the first place is to hold down the ALT key when selecting that you want your guest OS to use the USB device (LaunchPad) so that Parallels will remember the choice. That may allow it to reconnect to the Windows machine quick enough to not fail in the first place.

20

Robert thanks for sharing your experience!

We don’t have many (if any) Macs here at TI to test on, so it’s great to hear that it works, even if there are a few gotcha’s.