Using the TI LaunchPad from your KoP

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

[ayeckley]

Originally Posted by jhersh

If you only decode in 1X mode (rising edge on A only) then you have 1/4 the interrupts to process.

That was the plan. The detents are located at each 1/100th of rotation (same as the tick resolution), so we would never be able to capitalize on the added resolution that 2X or 4X would bring. I suppose if we cared about angular rates then 2X or 4X might be helpful, but for our current application we don't care about that.

[ILAMtitan]

Originally Posted by ayeckley

That was the plan. The detents are located at each 1/100th of rotation (same as the tick resolution), so we would never be able to capitalize on the added resolution that 2X or 4X would bring. I suppose if we cared about angular rates then 2X or 4X might be helpful, but for our current application we don't care about that.

What implementation did you use to read the encoder? The ones I've seen use a very short interrupt, and should have any issues with missed ISRs.

Any chance you can share your code or modifications? I should be able to run some timing analysis to see why you're missing counts, and run it by our USB expert when I'm back in the office on Monday.

[ayeckley]

To clarify, we haven't switched to the interrupt approach yet. That's just the eventual plan once we work through some higher-priority problems not related to the driver station. For now we've got our encoder working well enough to compete with if we really had to. We can share the source code but I have to travel for work so it might be a couple of days before I can post it. The students are generally reluctant to post on C-D.

Also, I see now that I was mistaken about the 10ms polling rate. The ADC conversions are done every 10ms, but there doesn't appear to be anything super-obvious that is throttling the polling loop (other than the time required to execute the ADC ISR). Shutting down that interrupt didn't improve the polled performance, which was a little counter-intuitive.

[ILAMtitan]

I was able to finally spend some time tinkering with the LaunchPad co-processor for the GamePad (had business travel late last week), and I have it to a point where it's ready to go for those interested.

The first thing you need to do if you want to stack the LaunchPads like I did (and only if you stack them), is to update the hex files for the GamePad tool. The co-processor uses only pins 2 and 3 on J1 (full pinout available here: http://energia.nu/img/LaunchPadMSP430F5529.jpg), and these needed to be changed to high impedance in the GamePad so they don't interfere with the co-processor. I've uploaded new hex files to my personal git hub account to replace the existing ones: https://github.com/ILAMtitan/FRCGamePad_CoProcHex

Just replace these in the FRC GamePad Tool firmware folder as denoted in the readme, and then reflash your GamePad LaunchPad.

To program the second LaunchPad as the LED animation generator, you'll need to pick up Energia: http://energia.nu/

Run it once to generate the library folder in your Documents directory, akin to how the Arduino IDE works. Once the library folder is there, you can install the WS2811 Driver I wrote for Energia: https://github.com/ILAMtitan/WS2811Driver
The included readme should get you running correctly. I've made a handful of updates recently that will make it much more robust and easy to use, so feel free to use it for other LED projects as well if you feel so inclined.

The last bit of code is the actual co-processor code: https://github.com/ILAMtitan/GamePadCoProcessor
It's a simple sketch for Energia that will generate frames based on the input from the Option1 GamePad indicators. If you use a different option, you'll just have to change the relevant IO settings in the application.

The Energia sketch will generate frames one at a time, and only display them when a timer tells it to. This is a little bit different from many of the Arduino usages I've seen, but it doesn't use a wait statement which essentially holds the processor hostage. The code is reasonably well documented, so it shouldn't be too hard to figure out, just tricky. This method does let you cancel and change an animation between frames though.

Once both boards are programed, just plug em together, attach the LEDs (5V, GND, and Pin3 for the data), and then attach the USB cable to the LaunchPad that is the GamePad. Go ahead and attach any other buttons of indicators that you want to use in your OI as well. I've tested with with 60 LEDs on the USB port without extra power, but if you run into issues with power, you can use one of these: http://www.ti.com/tool/boostxl-battpack

The fuel tank will also let you run the LED strip without the DS being on, which is a nice bonus.

Let me know if you guys manage to try it out and how it works for you, and if you find any bugs.

[billbo911]

Is there a chance there is a CAD file for this board. I know it's a minor part, but having accurate measurements would be nice.
I started to create one, but found hole spacing to not be ANSI Standard, so I decided to see if I ac find an official drawing before I spend the few minutes it will take to create it myself.

[ILAMtitan]

Originally Posted by billbo911

Is there a chance there is a CAD file for this board. I know it's a minor part, but having accurate measurements would be nice.
I started to create one, but found hole spacing to not be ANSI Standard, so I decided to see if I ac find an official drawing before I spend the few minutes it will take to create it myself.

I created a dimensioned drawing from the PCB layout for you guys to use. You can get it here for now: https://txn.box.com/s/iid65s2kh6e1qrde1hoea7o2ify1g0u1

I don't do much formal CAD work, but all the relevant information should be there. I'll run it by some of the people on our team who are better at making these kinds of drawings and get a more formal one up on the wiki later.

If you're familiar with EagleCAD, you can grab the full hardware design package from here as well: http://www.ti.com/tool/MSP-EXP430F5529LP

[billbo911]

Originally Posted by ILAMtitan

I created a dimensioned drawing from the PCB layout for you guys to use. You can get it here for now: https://txn.box.com/s/iid65s2kh6e1qrde1hoea7o2ify1g0u1

I don't do much formal CAD work, but all the relevant information should be there. I'll run it by some of the people on our team who are better at making these kinds of drawings and get a more formal one up on the wiki later.

If you're familiar with EagleCAD, you can grab the full hardware design package from here as well: http://www.ti.com/tool/MSP-EXP430F5529LP

Thanks Bart!
I can do a little math based on that PDF and get the details I need.
I'm still learning SolidWorks 2014, but I'm certain I can create what I need now. I'm looking forward to what your team creates so I can do a little self critique based on other's work.

[mplanchard]

Originally Posted by ILAMtitan

I created a dimensioned drawing from the PCB layout for you guys to use. You can get it here for now: https://txn.box.com/s/iid65s2kh6e1qrde1hoea7o2ify1g0u1

I don't do much formal CAD work, but all the relevant information should be there. I'll run it by some of the people on our team who are better at making these kinds of drawings and get a more formal one up on the wiki later.

If you're familiar with EagleCAD, you can grab the full hardware design package from here as well: http://www.ti.com/tool/MSP-EXP430F5529LP

Do you have and IDF or PADS file? I can bring it into CircuitWorks and get the 3D board. Marie

[ILAMtitan]

Originally Posted by mplanchard

Do you have and IDF or PADS file? I can bring it into CircuitWorks and get the 3D board. Marie

I had to import it into Altium, and then export the IDF file, but you can find it here: https://txn.box.com/s/syur2lhypaihegkm2rfupxi2h0f11ufr

I was also able to export the STEP file from Altium, but I know those aren't always preferred due to file size and other restrictions. I've uploaded here for any interested parties though: https://txn.box.com/s/c0b11817xbyn6nxorrejz9728f1bublo

Since both of these are both via Altium, I can't guarantee the accuracy. If anyone can validate them, please let me know.

[billbo911]

Please forgive me if this has been covered, but using my phone to search CD is rather difficult and I couldn't find it.
We have a driver's station setup with the Launchpad, that uses 18 buttons. Therefore, we have the Launchpad in mode 3. The problem is, we cannot see all of the buttons indicated on the driver's station. Is there a way to extend the driver station to display all 20 buttons as they are activated?

[mplanchard]

Originally Posted by ILAMtitan

I had to import it into Altium, and then export the IDF file, but you can find it here: https://txn.box.com/s/syur2lhypaihegkm2rfupxi2h0f11ufr

I was also able to export the STEP file from Altium, but I know those aren't always preferred due to file size and other restrictions. I've uploaded here for any interested parties though: https://txn.box.com/s/c0b11817xbyn6nxorrejz9728f1bublo

Since both of these are both via Altium, I can't guarantee the accuracy. If anyone can validate them, please let me know.

I will contact you through a private message - we are working with Altium and other formats. Have a few questions trying to get this into CircuitWorks. Marie