Using the TI LaunchPad from your KoP

[billbo911]

Originally Posted by wt200999

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.

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).

[ILAMtitan]

Originally Posted by billbo911

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).

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.

[billbo911]

Originally Posted by ILAMtitan

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 ..... the first LaunchPad can map to 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.

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!

[robert1356]

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/sh...ight=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.

[ILAMtitan]

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.

[feverittm]

I have been noting that some teams are thinking of connecting 'smart' led strings to their launchpad that is on their driver's station.

I thought that the current requirements of the WSxxxx type of addressable LED strings was much too high to connect to the regulator output from the launchpad (is the serial input on the leds 3.3V compatible?) or even USB power connections.

What are people thinking of using to provide power to these devices? Are you considering a second power plug (like a wall wart) to supply the additional current?

Thanks

Floyd Moore

[billbo911]

Originally Posted by feverittm

I have been noting that some teams are thinking of connecting 'smart' led strings to their launchpad that is on their driver's station.

I thought that the current requirements of the WSxxxx type of addressable LED strings was much too high to connect to the regulator output from the launchpad (is the serial input on the leds 3.3V compatible?) or even USB power connections.

What are people thinking of using to provide power to these devices? Are you considering a second power plug (like a wall wart) to supply the additional current?

Thanks

Floyd Moore

So, the current plan is to actually control an addressable string of LEDs with an Arduino. The Arduino will be interfaced to a couple of the Digital outputs on the LaunchPad to know what pattern to display. The Arduino and the LEDs will get their power from a LiPo battery through a UBEC. That way, if the LiPo is not there, or too low, the LEDs just won't work, but the rest of the DS will function normally.

[ILAMtitan]

Originally Posted by feverittm

I have been noting that some teams are thinking of connecting 'smart' led strings to their launchpad that is on their driver's station.

I thought that the current requirements of the WSxxxx type of addressable LED strings was much too high to connect to the regulator output from the launchpad (is the serial input on the leds 3.3V compatible?) or even USB power connections.

What are people thinking of using to provide power to these devices? Are you considering a second power plug (like a wall wart) to supply the additional current?

Thanks

Floyd Moore

Floyd, you're sort of right about the current limitation. The 3.3V rail of the LaunchPad is limited to what the DC/DC converter is capable of putting out. However, the 5V rail is directly connected to the USB output, and able to source 500mA. The SmartLEDs, like the WS2811 and WS2812, actually work better with a 5V source, and still run fine with the 3.3V digital serial output of the MSP430. The 500mA limit is problematic however, and running the LEDs off it can cause the host port to crash and resets of the MCU. It "works". Using a wall wart or other DC power supply is just fine if you connect the ground to the LaunchPad, and will enable you to source more current.

However, the LaunchPad is only capiable of running the SmartLEDs or the USB HID application, not both since they are both so timing critical dependent (I'm working on it though). If you're interested in just running LEDs, I've already made an Energia (http://energia.nu/) library for the LaunchPad to run the SmartLED strips. It emulates the AdaFruit NeoPixel library, and any Arduino code you already have for it should be 90% compatible with the LaunchPad via Energia. You can pick it up off my GITHub if you want to try it: https://github.com/ILAMtitan/WS2811Driver I'll be the first to admit it needs a readme, but it works just like the Arduino ones out there. If you need any support getting it running, just let me know.

Originally Posted by billbo911

So, the current plan is to actually control an addressable string of LEDs with an Arduino. The Arduino will be interfaced to a couple of the Digital outputs on the LaunchPad to know what pattern to display. The Arduino and the LEDs will get their power from a LiPo battery through a UBEC. That way, if the LiPo is not there, or too low, the LEDs just won't work, but the rest of the DS will function normally.

Since I want to do the same thing, I've kinda cobbled together a solution that I think works pretty well. I used a second LaunchPad to run the LED co-processor, which works well since they stack perfectly.



The middle board in the shot is the GamePad HID device using Option 1 from the utility. The top LaunchPad runs some code I wrote in Energia to read indicator pins 1-4 from the GamePad as a parallel input, and trigger prewritten animations based on the input code. All of the pins are set to HighZ otherwise, so they don't interfere with any of the GamePad functions. I ran some basic tests using an interface we wrote for the HID device testing, and the idea seems to work so far: https://www.youtube.com/watch?v=aLWZ5FOrozE

I also picked up the Fuel Tank Boosterpack I mentioned earlier to supply additional power, and enable the LEDs when it's unplugged: http://www.ti.com/tool/boostxl-battpack

There are a few caveats that I'm still working out (ie, it's super buggy still and very proof of concept), but I can post more info if you guys are interested.

[feverittm]

This looks really good. Please keep us informed on your progress.

Floyd Moore

[ayeckley]

Is there a recommended approach for using the LaunchPad to interface with a quadrature encoder? We're trying to replicate the capability that the Cypress PSoC offered in previous years via the Enhanced I/O interface on the Driver Station, but we're still pretty low on the learning curve re: how we could use the HID protocol (is that even the right terminology?) to duplicate or at least mimic it.

Ideally we'd like to pass the [signed, 16 bit] tick count from the encoder to the roboRIO and do all related processing there. We're a LabVIEW team.

Edit: OK, I've spent a few hours rolling around in the source code and I think I've found an approach that will work. It looks likes the struct for the button data could be modified so that 16 bits could still be used for button status and the remaining 16 bits can be used for the encoder data. HID appears to offer 8x16bits for "user data" as well, but its not clear if the DS forwards that to the roboRIO or not so that won't be our primary approach. If we get it working then I'll provide an update.

[wt200999]

Originally Posted by ayeckley

Ideally we'd like to pass the [signed, 16 bit] tick count from the encoder to the roboRIO and do all related processing there. We're a LabVIEW team.

Edit: OK, I've spent a few hours rolling around in the source code and I think I've found an approach that will work. It looks likes the struct for the button data could be modified so that 16 bits could still be used for button status and the remaining 16 bits can be used for the encoder data. HID appears to offer 8x16bits for "user data" as well, but its not clear if the DS forwards that to the roboRIO or not so that won't be our primary approach. If we get it working then I'll provide an update.

It depends on how the HID descriptor is defined and how the software utilizes it. On the LaunchPad we are sending 8 16-bit joystick inputs coming from the ADC for the axes, and up to 32 bits for buttons (though the default options give 11 16 or 20). You could use any of these to send the data, though you have to be mindful of how Windows and the driver station use the data.

The easiest way forward would be to use half the button data as you suggested. Each button is just one bit, and fairly easy to decode on the robot.

When Windows gets the joystick data, it plays with it a little, and stores calibration data somewhere in the registry. This is why we include a section on the wiki for calibrating your inputs, and if you are using analog it is quite convenient.

The following description here is based on my experimentation with the calibration and with LabVIEW (and the driver station's) input dll.

In the Windows calibration tool you can view the exact output that you send from the LaunchPad, and during this calibration Windows asks for a minimum, center and maximum value. From here it seems to scale it for the rest of the system. So in LabVIEW if I probe the wires from the dll call, no matter what the actual data is that I send from the LaunchPad, I get a range from -32767 to +32767 based on the range I calibrated. Anything outside of the calibrated range just saturates.

Lastly, when the driver station gets this data, each axis is converted to 8-bit and sent to the robot, and is then normalized to the -1 to 1 range.

So you certainly could send data this way, you would just need 2 'axes' for the 16 bits and have the LaunchPad send it as 8 bits. Then you would need to make sure Windows recognizes the range for the 2 axis. Finally on the robot you would need to convert back to the 8-bit data and repack the 2 axes.

Originally Posted by ayeckley

Is there a recommended approach for using the LaunchPad to interface with a quadrature encoder? We're trying to replicate the capability that the Cypress PSoC offered in previous years via the Enhanced I/O interface on the Driver Station, but we're still pretty low on the learning curve re: how we could use the HID protocol (is that even the right terminology?) to duplicate or at least mimic it.

I'm curious to learn a little more about your application from past years. I also was reading what you had posted in the Cypress thread. Do you have any pictures or examples of how you used this previously?

For your application, what encoder did you use? The LaunchPad is certainly capable of interfacing with an encoder, it just needs to be able to do that and send the USB packets out. An interrupt based solution would probably work well for you. We are happy to help support your team with this.

Also have you considered using an absolute encoder, something that maybe uses I2C or SPI?

[ayeckley]

Originally Posted by wt200999

I'm curious to learn a little more about your application from past years. I also was reading what you had posted in the Cypress thread. Do you have any pictures or examples of how you used this previously?

I'm searching for pictures of last year's DS now. I'll update if I'm able to track them down. Last year we used it for fine-tuning of our shooter angles, as well as for gross movements of the shooter when the desired position didn't correspond to the five presets we had established. When the target angle was achieved, an LED adjacent to the corresponding preset button would illuminate in case the operator didn't have a clear view of the robot. We used almost all of the discrete inputs and outputs of the Cypress PSoC. People complained about the reliability of it, but it never gave us a lick of trouble.

On the robot side, the shooter angle control was implemented via a closed-loop system using a Bournes pot for feedback. Since we only had a ~180 degree range of motion we didn't have to deal with the rollover issue I described in the other thread.

For your application, what encoder did you use? The LaunchPad is certainly capable of interfacing with an encoder, it just needs to be able to do that and send the USB packets out.

We use FANUC pulse generators recycled from CNC equipment which have gone to That Great Pile of Chips in the Sky. They have a knob that is very human-factor friendly -- about the size of the average palm and with micro-detents that provide an intuitive feedback to the operator -- and are very robust since they are designed for industrial use. The drawback this year (aside from what we've already discussed) is that are intended to operate at 5V; I'm going to be running a test later this morning to see if 3.3V is sufficient. If not then we'll have to build some simple level-translation circuitry since the LaunchPad is [so I'm told] not 5V tolerant on the inputs.

An interrupt based solution would probably work well for you. We are happy to help support your team with this.

Thanks for your support. Happily, I've been using MSP430 (off and on) for about 13 years now so I'm pretty comfortable with the hardware side of things. We may get into trouble with the software side but we were able to get the default code to compile using CCS last night which is a very positive first step. I see that the polling interval is 10ms, so I think we'll approach it from that angle first and then may fall back on an interrupt approach if need be. The kids are going to get a lot more exposure to embedded microcontrollers than we were anticipating.

Originally Posted by wt200999

Also have you considered using an absolute encoder, something that maybe uses I2C or SPI?

I guess we've lightly considered it, but haven't encountered a situation yet where we felt we couldn't achieve what we wanted using a relative encoder. Another one of our lessons-learned over the years is that the Drive Team will sometimes forget to put the DS in its required starting configuration. For that reason, one of our standard design practices is to have the robot only have relative control response. In other words, if nobody turns the knob at the start of Teleop then the robot stays in whatever state it was in at the end of Autonomous. If we used an absolute encoder and accidentally set it to the "wrong" position going into Teleop, then it could/would do something unintended at the start of the match and we'd have to spend time and energy recovering from it. It's a minor point, obviously, but we do try to squeeze as much performance out of things as we can.

[ayeckley]

Update:

We've verified that the FANUC pulse generator will work tolerably well using a 3.3VDC supply, although the output pulse train may be cutting it a bit close to the LVTTL threshold for input logic "high". More on that later.

We've succeeded in modifying the default LaunchPad-FRC software and inserting our encoder data into the HID data stream to the DS (and on to the robot). We discovered that the Read Joystick.vi automatically scales the button array size to the number of button bits received, which is a pleasant surprise since we were expecting to have to create a custom VI to do that for us. We're using the upper 16 bits of the button datatype for encoder values (allowing us to make 120+ full knob rotations in either direction before overflow occurs), and keeping the bottom 16 for actual button inputs or LED (etc.) outputs. We simply split the Button array output from the Read Joystick.vi in half and treat those upper bits as a signed 16-bit integer.

What we're currently having challenges with is "missing" ticks. The way things are implemented right now, we're not detecting about 30% of the encoder ticks that we are providing. It does seem to be rate-sensitive (proportionally more ticks are lost the faster the knob is turned). We've determined that the likely cause is due to use of a polled-input approach. The default code for the Launchpad-FRC polls at 10ms, but at a realistic knob-turning rate the rising edges of the ticks from Phase A can occur at ~5ms apart. Anyone see a problem there? By switching to an interrupt-based approach and a reasonably tightly-coded ISR we expect to resolve the issue [hopefully] without screwing up the interrupts used in the serial communications process. We considered simply increasing the speed of the polling loop, but since that would require a 4X increase in the rate we decided that the risk of unintended side-effects (such as screwing up the settling times of the ADC inputs) makes that a less-attractive option (for now). Who knows, we may just jack up the polling rate and see what happens; it's easy enough to undo.

Although the waveform is still a nicely shaped pulse train when using 3.3V to power the pulse generator, the output logic "high" from the pulse generator can be as low as 2V under some conditions, which is right on the hairy edge of the EIA-published standard for input logic high (don't have the MSP430 datasheet handy to see if it differs from the standard or not). We may need to add some circuitry to bring logic high closer to the power supply rail. Once we switch to the interrupt-based approach we should know if this will be important enough to worry about or not.

Thanks to anyone following along...

[billbo911]

Originally Posted by ayeckley

Update:

We've verified that the FANUC pulse generator will work tolerably well using a 3.3VDC supply, although the output pulse train may be cutting it a bit close to the LVTTL threshold for input logic "high". More on that later.

We've succeeded in modifying the default LaunchPad-FRC software and inserting our encoder data into the HID data stream to the DS (and on to the robot). We discovered that the Read Joystick.vi automatically scales the button array size to the number of button bits received, which is a pleasant surprise since we were expecting to have to create a custom VI to do that for us. We're using the upper 16 bits of the button datatype for encoder values (allowing us to make 120+ full knob rotations in either direction before overflow occurs), and keeping the bottom 16 for actual button inputs or LED (etc.) outputs. We simply split the Button array output from the Read Joystick.vi in half and treat those upper bits as a signed 16-bit integer.

What we're currently having challenges with is "missing" ticks. The way things are implemented right now, we're not detecting about 30% of the encoder ticks that we are providing. It does seem to be rate-sensitive (proportionally more ticks are lost the faster the knob is turned). We've determined that the likely cause is due to use of a polled-input approach. The default code for the Launchpad-FRC polls at 10ms, but at a realistic knob-turning rate the rising edges of the ticks from Phase A can occur at ~5ms apart. Anyone see a problem there? By switching to an interrupt-based approach and a reasonably tightly-coded ISR we expect to resolve the issue [hopefully] without screwing up the interrupts used in the serial communications process. We considered simply increasing the speed of the polling loop, but since that would require a 4X increase in the rate we decided that the risk of unintended side-effects (such as screwing up the settling times of the ADC inputs) makes that a less-attractive option (for now). Who knows, we may just jack up the polling rate and see what happens; it's easy enough to undo.

Although the waveform is still a nicely shaped pulse train when using 3.3V to power the pulse generator, the output logic "high" from the pulse generator can be as low as 2V under some conditions, which is right on the hairy edge of the EIA-published standard for input logic high (don't have the MSP430 datasheet handy to see if it differs from the standard or not). We may need to add some circuitry to bring logic high closer to the power supply rail. Once we switch to the interrupt-based approach we should know if this will be important enough to worry about or not.

Thanks to anyone following along...

Thanks for working on this!

Honestly, I think doing this under interrupt control will work out just fine. Please let us know what you find out, both good and bad.

[jhersh]

Originally Posted by ayeckley

We've determined that the likely cause is due to use of a polled-input approach. The default code for the Launchpad-FRC polls at 10ms, but at a realistic knob-turning rate the rising edges of the ticks from Phase A can occur at ~5ms apart. Anyone see a problem there? By switching to an interrupt-based approach and a reasonably tightly-coded ISR we expect to resolve the issue [hopefully] without screwing up the interrupts used in the serial communications process.

If you only decode in 1X mode (rising edge on A only) then you have 1/4 the interrupts to process. Seems pretty doable. Polled input had better have plenty of headroom to be reliable, but you've already discovered that.