paper: Driver Station Encoder Support using the TI LaunchPad

[KMBruggeman]

Thanks again for the reply. We are in a frenzy as well as our regional is next week.

That being said from a Labview post programming of the Launchpad, do you know of anyway I can read what the Launchpad is outputting to the USB port of the driver station (pre-processing).

Would I just use a USB sniffer? Additionally, IIRC if I put the reading routine in a custom dashboard I should be able to run it and check it's operation without having to connect the robot (real or otherwise simulated) right?

I spent a good amount of time on it last night and may post some snippets later on if I don't make more progress after looking at the user guide.

Cheers!

[ayeckley]

Originally Posted by KMBruggeman

do you know of anyway I can read what the Launchpad is outputting to the USB port of the driver station (pre-processing)

I'm not sure I understand the question. Are you asking if there's a way to access the raw USB datastream from the LaunchPad, without going thru the roboRio first? I'm afraid I don't know the answer to that. My recollection is that in past years this was not possible, although we never attempted exactly what you are describing (since the Enhanced I/O gave us everything we needed). With the new control system architecture that may have changed. If it could be done I'm confident it would require writing a Custom Dashboard (as I think you are suggesting).

[KMBruggeman]

That is what I was thinking - and since I have a custom dashboard was attempting to just put the custom Labview code with indicators on the "custom" tab of the dashboard to output the buttons and the encoder count.

I figured since I could see the buttons lighting up at the bottom of the driver station and in my custom dashboard I should be able to read that input without actually running "main.vi" to either a live robot or a simulated robot (to help out my old and wheezing processor).

I'm not seeing the button outputs though and when I tried to tie into the data stream that is on the standard dashboard project I was not getting anything from the Launchpad (My process is 1 encoder then modify to get a 2nd and if I have any hair and patience left maybe a 3rd).

That being said I am looking to see if there's a way I can "see" what's happening along the process to troubleshoot. (Similar to my cheap way of putting "Alert('here');" when doing poor man's javascript troubleshooting to see where the process is breaking down.

I see three critical places I would like to check thus far.

1 - Can I tell what software is actually loaded on the Launchpad? (Validate the software install) Currently when I use the little debug button I am getting HW stops where I have a steady red LED and I have to restart the Launchpad via unplugging/plugging it in. When setting the OPTION2 and OPTION3 flag it does show with the appropriate # of buttons afterwards via a Labview Custom DB.

2 - Is the Launchpad actually calculating a value for "encoder_count" and what is it? (Can I see this by using a tool in CCS?)

3 - What is the Launchpad sending via "gamepadReportTX.buttons"?
(Could I see this on my laptop with another tool? I would guess that I could use the LabView Custom Dashboard for this)

I know that's a bit lengthy but hopefully clears things up.

Also if I wanted to use say P1.3 and P1.2 would I need to delete them from the "Indicators" section of "OPTION1" in hal.c and replace two of the dummy inputs after P1.4 in the buttons section? e.g.

#define NUM_BUTTONS 32
#define NUM_INDICATORS 9

{GPIO_PORT_P1, GPIO_PIN4},
{GPIO_PORT_P1, GPIO_PIN3},
{GPIO_PORT_P1, GPIO_PIN2},
... dummy inputs ...

Thanks again for explaining this. If it would be easier I can provide a phone #.

Kurt

[wt200999]

I do not know if the HID data is transmitted from the driver station to the dashboard but I do not think it is. What are you planning on using the encoders for?

Another way you can consider for transmitting the data is to use serial on the dashboard and keep the HID to the driver station. The LaunchPad has a USB hub, so the debugger chip can also act as a USB <--> Serial bridge, and you can look at both the HID and the serial stream at the same time. You will just need to write software on the dashboard to detect and decode the serial stream.

[KMBruggeman]

The plan is to use it for arm control. The robot has the equivalent of a human arm from the shoulder to the wrist with the same joints. The plan is to have a scale version at the driver station to use to control it's movement so it's less clumsy than say driving a backhoe. (sp?)

I'll have to take a look at the reading in the serial stream (I assume it's more complicated than the standard create a constant for "USB0" ...)

[KMBruggeman]

As I was meandering through the code this afternoon I had this random thought. It looks the axis values are defined in "USB_gamepad.h" source such that they are contained in the data structure "USB_GamepadReportTx".

https://github.com/TI-FIRST/MSP430-G.../USB_gamepad.h

If I look at that it appears that *.ax, *.ay, etc are all 16bit integers. Could I modify the code from https://github.com/TI-FIRST/MSP430-G...b/master/hal.c (line 517)

from: "gamepadReportTx.ax = Convert8Bit(ADC12_A_getResults(ADC12_A_BASE, ADC12_A_MEMORY_12));"
to "gamepadReportTx.ax = encoder_count;" as that would allow me in essence to have up to 8 x 16BIT signed integers in my HID data stream?

(gamepadReportTx is defined on line 151 to type USB_GamepadReportTX from the first linked file.)

I would then just need to see how LV views/processes that data converting it into a float with the range -1.0 to 1.0 but my guess would be by dividing it by 2^15 ...

Am I totally off base here or is my lack of sleep starting to pay off?

[ayeckley]

Originally Posted by KMBruggeman

If I look at that it appears that *.ax, *.ay, etc are all 16bit integers. Could I modify the code from https://github.com/TI-FIRST/MSP430-G...b/master/hal.c (line 517)

from: "gamepadReportTx.ax = Convert8Bit(ADC12_A_getResults(ADC12_A_BASE, ADC12_A_MEMORY_12));"
to "gamepadReportTx.ax = encoder_count;" as that would allow me in essence to have up to 8 x 16BIT signed integers in my HID data stream?

I believe that would work.

[wt200999]

Originally Posted by KMBruggeman

The plan is to use it for arm control. The robot has the equivalent of a human arm from the shoulder to the wrist with the same joints. The plan is to have a scale version at the driver station to use to control it's movement so it's less clumsy than say driving a backhoe. (sp?)

Are you are using an incremental encoder to develop this? How are you planning on getting an absolute value for the arms?

[ayeckley]

Big Picture Thought first: If you are intending to control a jointed arm, it might make more sense to use potentiometers and the analog inputs on the Launchpad instead of quadrature encoders. You wouldn't have to modify the default FRC Launchpad code to do that. You could just go directly to the Ax, Ay, Az etc. inputs.

Originally Posted by KMBruggeman

I figured since I could see the buttons lighting up at the bottom of the driver station and in my custom dashboard I should be able to read that input without actually running "main.vi" to either a live robot or a simulated robot (to help out my old and wheezing processor).

Right, the encoders will still be "live" even if the roboRio code is not running, and you should see flashing virtual LEDs on the DS corresponding to the buttons that have been "stolen" for the encoder (unless you remove them from the "raw" button datastream, which we didn't). We've found that seeing the button states is very useful for diagnostic purposes.

I'm not seeing the button outputs though and when I tried to tie into the data stream that is on the standard dashboard project I was not getting anything from the Launchpad.

That sounds consistent with previous years then; you'd may have to transmit that data back to a Custom Dashboard from the roboRIO using the Smart Dashboard/Network Table feature.

1 - Can I tell what software is actually loaded on the Launchpad? (Validate the software install) Currently when I use the little debug button I am getting HW stops where I have a steady red LED and I have to restart the Launchpad via unplugging/plugging it in.

Perhaps a breakpoint is set? Unlike the roboRIO, code on the Launchpad doesn't/can't run in RAM - just Flash memory. Whenever you hit Debug, it's overwriting the old Flash contents with the new. About the only way to know what's currently loaded into Flash would be via the checksum.

2 - Is the Launchpad actually calculating a value for "encoder_count" and what is it? (Can I see this by using a tool in CCS?)

In theory you should be able to see the value using the Variables tab in Debug mode, but for some reason that didn't work for us (even thought it's declared as a STATIC). What you might try instead is setting breakpoints at places of interest within the ISR to see what it "thinks" it's doing.

Could I see this on my laptop with another tool? I would guess that I could use the LabView Custom Dashboard for this

Dunno, sorry.

Also if I wanted to use say P1.3 and P1.2 would I need to delete them from the "Indicators" section of "OPTION1" in hal.c and replace two of the dummy inputs after P1.4 in the buttons section?

I don't have the info re: the original OPTION1 configuration handy at the moment, but in general yes - if OPTION1 configures those as outputs (indicators) they you'd need to change them to inputs (buttons) instead. Maybe that's what's going wrong.

I've got your email address; I'll try to drop you a line later tonight. It might be best if you .zip up your code for me to take a look at. I'll bring a Launchpad and two encoders home to work with.

[KMBruggeman]

I also was pushing for the potentiometer solution but it met with much resistance based upon the idea that it would be less precise.

In any case I have posted the code in .zip file here. I commented out some ideas I had and tried to run it as pure to your example.

https://onedrive.live.com/redir?resid=94CA3E1384343D7D!1159&authkey=!AM07Cq1 eGOhWI68&ithint=file%2czip

Here's some screen shots below of the HW Breakpoints

https://onedrive.live.com/redir?resi...nt=photo%2cPNG

https://onedrive.live.com/redir?resi...nt=photo%2cPNG

kmbworkemail@gmail.com

[KMBruggeman]

I was planning on resetting to a known home position to re-zero required. When doing so I would re-zero the encoders on the robot and essentially us the current encoder count from the launchpad as the new 0 ref point.

[Steven Smith]

I also was pushing for the potentiometer solution but it met with much resistance