Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   FRC Control System (http://www.chiefdelphi.com/forums/forumdisplay.php?f=176)
-   -   Driver Station Usb (http://www.chiefdelphi.com/forums/showthread.php?t=77903)

biojae 18-07-2009 00:16
Driver Station Usb
 
This year we were only able to use usb-hid joysticks attached to the DS, (as well as the 8 io and 4 analog). but my team would like to make our own pseudo joystick, using a microcontroller like an arduino. Would a usb-serial device (an FTDI chip) be able to be used on the driver station? :) or would i have to do something like AvrUsb on the mcu? :(

RyanCahoon 18-07-2009 07:15
Re: Driver Station Usb
 
[Explanation of USB device classes]
The USB specification contains several predefined "classes" of devices, each of which has a corresponding protocol of commands that are sent between the USB host (in this case the DS) and the USB device (the joystick). HID (Human Interface Device) is one such device class, CDC (Communication Device Class, the class most commonly used for USB-serial devices like FTDI chips) is another. These classes allow USB hosts to use generic drivers for devices that are connected to them, instead of requiring a driver for each specific device. The designers of the FIRST control system like this because it means that they only need one driver to be able to interface with almost every USB joystick (there are some exceptions, such as the Xbox controllers, which have been noted previously).

Because each device class has its own unique set of commands, a device that does not implement the HID class will not be able to work as a joystick. It will not be identified to the host as a HID device, and even if the host could be tricked somehow, the device would not know how to respond to the commands being sent. As a side note, the USB commands are also at a lower level than the serial data sent through a USB-serial device, which is itself encapsulated in USB data packets, so it's not simply a matter of sending the right serial data over a USB-serial device.

[What your microcontroller needs to do]
In order to be used as a USB HID device, your microcontroller will either have to be connected 1) to another chip that formats the data into the format of HID packets, such as maybe taking apart an old joystick and wiring the various buttons and potentiometers to digital and analog outputs, respectively, on your microcontroller, or 2) directly to the USB bus, such as in the AVR USB design.

[My recommendations]
I do not have any experience with AVR USB, and if they already have code that implements the right sections of the HID class, that could be a very viable method. However, I have made attempts before to implement USB on other devices, and while it is possible, it's not fun to wade through the specification documents. If you use a microcontroller with digital and analog outputs, another option instead of wiring it to an old joystick is to simply wire it into the exposed analog and digital input headers on the side of the DS. This is what most teams use when adding their own custom controls.

Good luck,
--Ryan

IndySam 18-07-2009 13:57
Re: Driver Station Usb
 
I would be very surprised if we have the same drivers station next year. So who knows what input will be avaliable.

biojae 18-07-2009 17:16
Re: Driver Station Usb
 
is it possible to bitbang the io pins on the ds fast enough for ttl level serial?
we are building a touchscreen inteface to the driver station for autonomous mode, with liquidware's touchshield slide. if we could use the io pins then that could free up a lot of programming time

EricVanWyk 19-07-2009 00:25
Re: Driver Station Usb
 
Quote:
Originally Posted by RyanCahoon (Post 867092)
...
QFT

FTDI isn't the easiest way to go about this - http://www.ftdichip.com/Support/Know...icesappear.htm

Many microcontrollers will have demo code that will do what you want. I know firsthand that code for PSoCs and PICs are available, and I'd be surprised if any USB-device capable uP didn't have it.

RyanCahoon 19-07-2009 00:58
Re: Driver Station Usb
 
Quote:
Originally Posted by biojae (Post 867130)
is it possible to bitbang the io pins on the ds fast enough for ttl level serial?
we are building a touchscreen inteface to the driver station for autonomous mode, with liquidware's touchshield slide. if we could use the io pins then that could free up a lot of programming time
Theoretically, yes, you could use the digital inputs as a TTL serial line, as they run at 5 volts. However, you will only get you 50 baud, as the DS updates at 50 Hz (source). Using parallel inputs will get you 50 * 12 inputs = 600 baud (assuming you repurpose the analog inputs as digital). Either way, you will probably have to establish some sort of flow control using one of the digital outputs, flipping it each time an update is sent to the DS by the cRIO. Even with this, however, you still stand a pretty good chance of data corruption because there's no reliable way to know when the DS's inputs are being sampled in relation to when the outputs are refreshed, the actual data is sent to the cRIO, or any other step in that process, so to be safe you would have to hold the data values across two transmission cycles, halving your data rate.

So in short, while it is possible, I believe you would be better off mapping the analog and digital inputs to the controls exposed on the touch screen, perhaps using digital potentiometers to output analog values if necessary. What kind of interface are you trying to develop on the touchscreen?

--Ryan

biojae 19-07-2009 02:31
Re: Driver Station Usb
 
The screen would be used to determine the position and place the robot should travel to during the auto period. the screen would be powered before the match and the position would be saved to eeprom, so on the next power up it would report to the crio a cartesian point (or points if possible) with rotation. so it would have to be read before the robot is enabled

RyanCahoon 20-07-2009 02:24
Re: Driver Station Usb
 
Quote:
Originally Posted by biojae (Post 867187)
The screen would be used to determine the position and place the robot should travel to during the auto period. the screen would be powered before the match and the position would be saved to eeprom, so on the next power up it would report to the crio a cartesian point (or points if possible) with rotation. so it would have to be read before the robot is enabled
If this is only to adjust auto-mode settings before the match, is there a reason you can't directly interface the touch screen with the robot itself instead of having to send the data over the wireless link? You could then even have the freedom to use a direct ethernet interface, setting up a server to run on the robot, which your touchscreen device could then connect to over a crossover ethernet cable. Depending on what your purpose was in developing this functionality, you might even be able to create the interface on a laptop instead of having to create your own embedded device.

As a side note, for other suggestions on how to rapidly set autonomous mode parameters, see this thread.

Of course. none of this applies if you need this functionality during matches as well.

--Ryan

biojae 20-07-2009 03:52
Re: Driver Station Usb
 
Though, im sure if i got it working for auto, then they'd want to use it for an operator control :ahh:, so an interface to the DS would be best.
what baud could be obtained through usb? HID is for the most part uni-directional, so an output pin could be used to signal auto / tele modes.
and have it dynamically update the controls.

Do you know of any cheap ethernet controllers for mcus? your last point could make it into a small dashborad :cool: Telemetry, speed and other statuses could be displayed, and have it for times not in a comp :yikes:

RyanCahoon 21-07-2009 00:42
Re: Driver Station Usb
 
Quote:
Originally Posted by biojae (Post 867258)
Though, im sure if i got it working for auto, then they'd want to use it for an operator control :ahh:, so an interface to the DS would be best.
True, I could see that kind of interface getting addictive... :p

Quote:
Originally Posted by biojae (Post 867258)
Do you know of any cheap ethernet controllers for mcus? your last point could make it into a small dashborad :cool: Telemetry, speed and other statuses could be displayed, and have it for times not in a comp :yikes:
There's a couple of different ways you could go with this:
  • Slightly higher-end microcontrollers often have ethernet interfaces built in. Many of these same controllers are also able to run Linux, which gives you the standard network suite (ifconfig, etc) that you'll be familiar with if you've ever used a Unix-like system. The chip that I have the most experience with in this category is the Avr32 from Atmel. Certain models of the Avr32 chips also have builtin LCD controllers, which you may be able to use to output to your touchscreen. Linux drivers for the LCD controller are included, I believe. For more information, check out Atmel's site or the user forum at Avrfreaks.net. If you choose to go this route, Atmel makes "evaluation boards" that basically save you the effort of having to design and fab PCBs yourself. They're a little on the pricey side, but I still feel they're a good deal for what you get in the package.
  • Alternatively, if you already have a system design in place and just want to add on ethernet functionality, there are several makes of ethernet to TTL serial converters. While I have not used any myself, I can pass along many good recommendations I've heard about Lantronix's modules. The XPort line seems to be about what you want. The $50 price tag may seem like a lot, especially compared to the price you may be able to find on a raw IC that accomplishes the same purpose, but, again, this gives you an already assembled package, and it's all about saving yourself the effort of having to solder tiny traces onto a PCB.
  • If you want a completely assembled board, but don't want to go as far as the Avr32 eval boards, you may be able to find somehing like this board from SparkFun (this one built around a PIC).

One thing to consider though is that FIRST has been very particular in the past about what types of devices can plug into the control inputs of the DS/OI. They might not allow your interface to be both connected as a dashboard and as a controller. <Insert disclaimer that I've never been a robot inspector and that rules are subject to change without warning from year to year anyway>

Quote:
Originally Posted by biojae (Post 867258)
what baud could be obtained through usb?
Even USB 1 can get 12 Mbsp, but since you're limited to packing your data into the amount of data that the joystick would be sending, I doubt you'll be able to get any more data through the USB ports than you will through the exposed analog and digital inputs. It's just a matter of how the input data is being sent to the processor in the DS; it all eventually gets packed into the data packets that only get sent at 50Hz.

--Ryan

biojae 21-07-2009 02:04
Re: Driver Station Usb
 
Well, does the lantronix xport have an output saying if an ethernet cord is plugged in?
if so, then the board could dedicate all processing time to the parsing of dashboard data and ignore the touchscreen
(it would still get power from the DS though and the oled screen would be showing the data)
or it could send the commands for auto then switch to a dashboard display and disable the touchscreen, the dashboard data has the game mode in it right?

RyanCahoon 22-07-2009 07:19
Re: Driver Station Usb
 
Quote:
Originally Posted by biojae (Post 867365)
Well, does the lantronix xport have an output saying if an ethernet cord is plugged in?
According to the datasheet on the Lantronix website, yes.

Quote:
Originally Posted by biojae (Post 867365)
if so, then the board could dedicate all processing time to the parsing of dashboard data and ignore the touchscreen
(it would still get power from the DS though and the oled screen would be showing the data)
or it could send the commands for auto then switch to a dashboard display and disable the touchscreen, the dashboard data has the game mode in it right?
I'm still a little fuzzy on how you're planning on sending the data entered onto the touchscreen to the robot. If you're planning on sending it through the inputs on the DS, then yes you should be able to detect the game mode through the dashboard ethernet port and send the data at the appropriate times. My previously stated concern over the legality of having something attached as both a dashboard and controller would then still apply; not to overly discourage you.

Just to clarify, though, you won't be able to send data back to the robot through the dashboard ethernet port (based on this year's rules/field setup), as the DS blocks all traffic besides the dashboard packets coming from the robot when it is in competition mode.

I would also warn against trying to draw power from the DS. According to the information provided in the control system manual, the DS is only rated for 900 mA, total system current. I don't know what the exact specification on the exposed power pins are, but I'd be surprised if you could draw much more than 150 mA, since they're intended to be used primarily for pullup sources or similar. That may be enough to power a microcontroller by itself, but the driver for your display alone is going to draw considerably more than that.

--Ryan

biojae 22-07-2009 18:32
Re: Driver Station Usb
 
Quote:
Originally Posted by RyanCahoon (Post 867469)
I'm still a little fuzzy on how you're planning on sending the data entered onto the touchscreen to the robot. If you're planning on sending it through the inputs on the DS, then yes you should be able to detect the game mode through the dashboard ethernet port and send the data at the appropriate times. My previously stated concern over the legality of having something attached as both a dashboard and controller would then still apply; not to overly discourage you.
i was thinking of using a digital potentiometer into the Driver station

Quote:
Originally Posted by RyanCahoon (Post 867469)
Just to clarify, though, you won't be able to send data back to the robot through the dashboard ethernet port (based on this year's rules/field setup), as the DS blocks all traffic besides the dashboard packets coming from the robot when it is in competition mode.
i wouldn't, what i was saying was that it could send the position through the analog in, and then be used as a dashboard for the rest of the match, so for 95% of the game its an output onto the screen

Quote:
Originally Posted by RyanCahoon (Post 867469)
I would also warn against trying t t know what the exact specification on the exposed power pins are, but I'd be surprised if you could draw much more than 150 mA, since they're intended to be used primarily for pullup sources or similar. That may be enough to power a microcontroller by itself, but the driver for your display alone is going to draw considerably more than that.

--Ryan
could the 5v lines be connected in parallel?

RyanCahoon 23-07-2009 01:13
Re: Driver Station Usb
 
Quote:
Originally Posted by biojae (Post 867536)
i wouldn't, what i was saying was that it could send the position through the analog in, and then be used as a dashboard for the rest of the match, so for 95% of the game its an output onto the screen
Ok cool.

Quote:
Originally Posted by biojae (Post 867536)
could the 5v lines be connected in parallel?
I did a little more looking, and I stand corrected on my previous assumption:

Quote:
<R84>
Please note that the power available through the USB ports, digital I/O, and analog input pins is limited to 2 amps total. Care must be taken to ensure that any team-provided devices connected to these sources do not over tax the available Driver Station supplied power.
Seeing as your joysticks will be drawing some power as well, I'd say you'd be safe with 1700mA. But yes, I would suggest ganging several of the power connectors if you're going to be drawing that kind of current. Just to be safe ;)

Note, however, that the wall wart supplied in the KoP is only rated for 1000mA, so you'll have to make other arrangements to supply the needed power while developing the system.

--Ryan

biojae 23-07-2009 02:55
Re: Driver Station Usb
 
well this is the screen that will be used
http://www.liquidware.com/shop/show/...chShield+Slide
i don't know its power usage, (plus an xport ethernet, and arduino (atmega 168)), hopefully it not going to be too much

EricVanWyk 23-07-2009 09:51
Re: Driver Station Usb
 
One option would be to use the analog inputs - you might be able to produce two voltages proportional to the X and Y axis on the screen.

My favorite method is still to pretend to be a USB joystick.

Quote:
Originally Posted by RyanCahoon (Post 867572)
Ok cool.
Seeing as your joysticks will be drawing some power as well, I'd say you'd be safe with 1700mA. But yes, I would suggest ganging several of the power connectors if you're going to be drawing that kind of current. Just to be safe ;)

Note, however, that the wall wart supplied in the KoP is only rated for 1000mA, so you'll have to make other arrangements to supply the needed power while developing the system.

--Ryan
The wallwart supplies 1000mA@12V. This is enough power to create 2000mA@5V using a switching regulator. Perfect Linear regulators are current in = current out. Perfect Switching regulators are power in = power out. Reality doesn't match ideal: (most) Linear regulators will draw a little extra current, and typical switching regulators are ~90% efficient.

The actual pins on the DS can safely handle 1 Amp each, so 2 should be fine.

biojae 23-07-2009 19:58
Re: Driver Station Usb
 
Quote:
Originally Posted by EricVanWyk (Post 867597)
One option would be to use the analog inputs - you might be able to produce two voltages proportional to the X and Y axis on the screen.
Yeah, thats what i was thinking of doing,
take 3 analog pins
1 X
2 Y
3 Point #
and update per point on screen

Quote:
Originally Posted by EricVanWyk (Post 867597)
My favorite method is still to pretend to be a USB joystick.
Yes, that would be very cool, but i'm not sure if theres enough memory on the atmega 168 for that (the screen + usb is almost all the available memory and ram)

Quote:
Originally Posted by EricVanWyk (Post 867597)
The wallwart supplies 1000mA@12V. This is enough power to create 2000mA@5V using a switching regulator. Perfect Linear regulators are current in = current out. Perfect Switching regulators are power in = power out. Reality doesn't match ideal: (most) Linear regulators will draw a little extra current, and typical switching regulators are ~90% efficient.

The actual pins on the DS can safely handle 1 Amp each, so 2 should be fine.
How much power does the competition port provide in a competition?

Schnabel 24-07-2009 00:22
Re: Driver Station Usb
 
****PLEASE NOTE: I have very little experience programming, so what I am about to say may not work, it is just an idea.****

I was just thinking, if you really want a touchscreen device, use an iPod touch or iPhone. With the release of OS 3.0, Apple opened up the possibility of utilizing the usb connector for outside devices. Maybe you could build a program for the iPod/iPhone to emulate a HID and get it to connect to the DS.

biojae 24-07-2009 01:07
Re: Driver Station Usb
 
Quote:
Originally Posted by Schnabel (Post 867681)
****PLEASE NOTE: I have very little experience programming, so what I am about to say may not work, it is just an idea.****

I was just thinking, if you really want a touchscreen device, use an iPod touch or iPhone. With the release of OS 3.0, Apple opened up the possibility of utilizing the usb connector for outside devices. Maybe you could build a program for the iPod/iPhone to emulate a HID and get it to connect to the DS.
The referees may not allow it due to the many types of wireless communication that it can do (wifi, bluetooth, cell phone) and i don't know if its a usb host, if its not a HID implementation my not be possible

biojae 24-07-2009 02:02
Re: Driver Station Usb
 
While i wait for everything to arrive (Slowwww mail :mad: ), i have almost finalized how its going to work (Ethernet pending)

3 Analog inputs on the driver station,
#1 X input 100 points of resolution (Have to account for Electrical noise)
#2 Y input 100 points
#3 Point # 50 points (To reduce waypoint navigation math)
1 digital in
#1 to signify point # change
1 Digital out
#1 To signify robot received point

1 digital potentiometer to the arduino and driver station

liquidware touchshield slide to arduino to digital potentiometer

RyanCahoon 24-07-2009 06:35
Re: Driver Station Usb
 
Quote:
Originally Posted by EricVanWyk (Post 867597)
The wallwart supplies 1000mA@12V. This is enough power to create 2000mA@5V using a switching regulator..
Thanks for the correction. I was assuming that they used linear regulators.

Quote:
Originally Posted by biojae (Post 867689)
3 Analog inputs on the driver station,
#1 X input 100 points of resolution (Have to account for Electrical noise)
#2 Y input 100 points
#3 Point # 50 points (To reduce waypoint navigation math)
1 digital in
#1 to signify point # change
1 Digital out
#1 To signify robot received point
Looks good. One suggestion might be to treat digital input as a "valid data" input instead of your current usage. My thought was since the point number input will already be changing (5 ticks difference between point numbers should be distinguishable), you don't really need to inform the robot that the data has changed, but using a valid data bit would handle the case where the DS's inputs get sampled while arduino/digital potentiometer is in the process of changing its outputs. So your update process would go like this:

Code:
set valid data bit to 0
update arduino's outputs
wait a couple milliseconds to give the digital potentiometer time to settle
set valid data bit to 1
wait for data received bit to change
then on the robot

Code:
if valid data pin is 1:
        update x and y coordinates of point
        flip data received bit
--Ryan

biojae 24-07-2009 17:11
Re: Driver Station Usb
 
Quote:
Originally Posted by RyanCahoon (Post 867694)
Thanks for the correction. I was assuming that they used linear regulators.



Looks good. One suggestion might be to treat digital input as a "valid data" input instead of your current usage. My thought was since the point number input will already be changing (5 ticks difference between point numbers should be distinguishable), you don't really need to inform the robot that the data has changed, but using a valid data bit would handle the case where the DS's inputs get sampled while arduino/digital potentiometer is in the process of changing its outputs. So your update process would go like this:

Code:
set valid data bit to 0
update arduino's outputs
wait a couple milliseconds to give the digital potentiometer time to settle
set valid data bit to 1
wait for data received bit to change
then on the robot

Code:
if valid data pin is 1:
        update x and y coordinates of point
        flip data received bit
--Ryan
So something like this on the robot side
Code:
bool DsPoints[100][100];
int validDataPin = 0;
int stopPin = 1;
int recievedPin = 0;
bool stop = false;

void DisabledPeriodic(void)  {
if(ds->GetDigitalIn(validDataPin) && !stop)
{
    int X = (int) ((float)ds->GetAnalogIn(0)/10.24); // 0 - 100
    int Y = (int) ((float)ds->GetAnalogIn(1)/10.24); // 0 - 100
    int pointNum = (int) ((float)ds->GetAnalogIn(2)/20.48); // 0 - 50
    if(pointNum == 50 || ds->GetDigitalIn(stopPin)) stop  = true; // Max 50
    DsPoints[X][Y] = true;
    ds->SetDigitalOut(recievedPin, true);
}
if(stop) calculateRoute();
}
though the highest resolution digi pot i can find is 256 step

EricVanWyk 24-07-2009 18:59
Re: Driver Station Usb
 
Quote:
Originally Posted by biojae (Post 867752)
though the highest resolution digi pot i can find is 256 step
I'm not a big fan of using digital pots in this manner. You could use a Digital to Analog Converter (DAC), or you could duty cycle modulate one of your arduino's pins and follow it with an RC filter.

EDIT: If you do want to use a higher resolution digital pot, the AD5292 has 1024 steps. Still, digital pots aren't designed for this type of use.

biojae 24-07-2009 19:34
Re: Driver Station Usb
 
Quote:
Originally Posted by EricVanWyk (Post 867763)
I'm not a big fan of using digital pots in this manner. You could use a Digital to Analog Converter (DAC), or you could duty cycle modulate one of your arduino's pins and follow it with an RC filter.

EDIT: If you do want to use a higher resolution digital pot, the AD5292 has 1024 steps. Still, digital pots aren't designed for this type of use.
What values of R and C would i need on the low pass filter for PWM?

EricVanWyk 24-07-2009 19:54
Re: Driver Station Usb
 
Quote:
Originally Posted by biojae (Post 867765)
What values of R and C would i need on the low pass filter for PWM?
Good question!

Your update rate is 50Hz (times per second), so you want to be sure that you can change at least that quick. Lets target 100-200 Hz for our filter.

An RC filter's cutoff frequency is 1/ (2 * pi * R * C) . Play with this calculator http://www.muzique.com/schem/filter.htm to find good values. The default 10k and 0.1uF would probably work well. *

This places the filter at about 160Hz. Make sure your DCM** signal is significantly quicker than that (2kHz? faster?) and you should be good to go!


* If you double R, you can cut C in half. So, how do you choose a value? Basically, pick what you can get, and don't let R get too big (over 100k).

** People often say PWM (Pulse Width Modulated) when they mean DCM (Duty Cycle Modulated). I make sure my students know which one they really care about - do they care how long the pulse is, or do they care about the duty cycle? Put more clearly, if your base frequency changes what needs to stay the same?

biojae 25-07-2009 01:37
Re: Driver Station Usb
 
i have a large supply of resistors, but can only find 10 uf capacitors and larger

RyanCahoon 25-07-2009 05:35
Re: Driver Station Usb
 
Quote:
Originally Posted by biojae (Post 867752)
So something like this on the robot side
Code:
bool DsPoints[100][100];
int validDataPin = 0;
int stopPin = 1;
int recievedPin = 0;
bool stop = false;

void DisabledPeriodic(void)  {
if(ds->GetDigitalIn(validDataPin) && !stop)
{
    int X = (int) ((float)ds->GetAnalogIn(0)/10.24); // 0 - 100
    int Y = (int) ((float)ds->GetAnalogIn(1)/10.24); // 0 - 100
    int pointNum = (int) ((float)ds->GetAnalogIn(2)/20.48); // 0 - 50
    if(pointNum == 50 || ds->GetDigitalIn(stopPin)) stop  = true; // Max 50
    DsPoints[X][Y] = true;
    ds->SetDigitalOut(recievedPin, true);
}
if(stop) calculateRoute();
}
Pretty much, except if you notice, there's nothing that ever causes the receivedPin to change from true, so I'd suggest something like
Code:
ds->setDigitalOut(receivedPin, !ds->GetDigitalOut(receivedPin));
You also might want to consider not stopping the update process after point 50, but instead allowing it to start over from the beginning again, which would allow last minute changes to the autonomous strategy if necessary, and also in case for some reason one of the points got skipped the first time through.

--Ryan

biojae 25-07-2009 16:13
Re: Driver Station Usb
 
well i forgot that part, the hard part is going to be in calculateRoute though :rolleyes:

biojae 03-08-2009 20:39
Re: Driver Station Usb
 
well i got the digital pots in the mail today (couldn't get low pass to work properly). first try on the arduino and it works! They are 10k 256 step pots
(Maxim ds1803).
waiting for the screen now.

RyanCahoon 04-08-2009 00:05
Re: Driver Station Usb
 
Awesome! Let us know how the rest goes.

--Ryan

biojae 04-08-2009 02:37
Re: Driver Station Usb
 
simple test program for arduino which i am using for the pots right now

Code:
#include <Wire.h>

void setup()
{
  Wire.begin(); // join i2c bus (address optional for master)
}

byte value = 0;
byte ch1 = 0x28;
byte ch2 = 0x29;
byte pot1 = 0xA9;
byte pot2 = 0xAA;

void loop()
{
 writePot(ch1, pot1, value);
 writePot(ch1, pot2, value);
 writePot(ch2, pot1, value);
 writePot(ch2, pot2, value);

  value++;        // increment value
  if(value == 256)
  {
    value = 0;    // start over from lowest value
  }
  delay(100);
}

void writePot(int chip, int pot, int val)
{
  Wire.beginTransmission(chip); // transmit to device 0x28)
  Wire.send(pot);            // sends instruction byte,
                              // write to potentiometer-0
  Wire.send(val);            // sends potentiometer value byte
  Wire.endTransmission();    // stop transmitting
}

biojae 04-08-2009 19:18
Re: Driver Station Usb
 
here is the code for the arduino, the touchscreen has its own processor that talks over ttl serial to the arduino
the arduino takes the output from the screen to the DS io pins

Code:
#include <Wire.h>
#include <AFSoftSerial.h>
#define rxPin 3
#define txPin 2

AFSoftSerial touchscreen = AFSoftSerial(rxPin, txPin);

byte ch1 = 0x28;
byte ch2 = 0x29;
byte pot1 = 0xA9;
byte pot2 = 0xAA;

int stopPin = 4, newData = 5, validRx = 6;

void setup()
{
  pinMode(rxPin, INPUT);//set recieve as an input
  pinMode(txPin, OUTPUT);//set transmit as an output
  pinMode(stopPin, OUTPUT);
  pinMode(newData, OUTPUT);
  pinMode(validRx, INPUT);
  touchscreen.begin(9600);
  Wire.begin(); // join i2c bus (address optional for master)
}

int points = 0;
bool stop = false;

void loop()
{
  int x = 0, y = 0;
  boolean recieved = digitalRead(validRx);
  boolean changePoint = touchscreen.available() >= 2
              && (recieved || points == 0)
              && !stop;
 
  if(stop){
    digitalWrite(newData, LOW);
    digitalWrite(stopPin, HIGH);
  }           
 
  if(recieved){
      digitalWrite(newData, LOW);
      delay(100);
  }
 
  if(changePoint)
  {
    x = touchscreen.read();
    y = touchscreen.read();
    if(touchscreen.available() == 1 && touchscreen.read() == 's')
          stop = true;
         
    points++;
   
    if(points >= 50)
          stop = true;
     
    writePot(ch1, pot1, x * 2);
    writePot(ch1, pot2, y * 2); //
    writePot(ch2, pot1, points * 5); // point num
    digitalWrite(newData, HIGH);
  } 
 
}

void writePot(int chip, int pot, int val)
{
  Wire.beginTransmission(chip); // transmit to device 0x28)
  Wire.send(pot);            // sends instruction byte,
                              // write to potentiometer-0
  Wire.send(val);            // sends potentiometer value byte
  Wire.endTransmission();    // stop transmitting
}

biojae 05-08-2009 20:50
Re: Driver Station Usb
 
1 Attachment(s)
digi pots on breadboard, just waiting to be soldered

biojae 12-08-2009 01:32
Re: Driver Station Usb
 
1 Attachment(s)
now all thats missing is the screen and prototyping shield

The Pwm wires plug into the drivers station, which go to a db9 connector. the db9 is used so that the drivers dont have to unplug the PWMs to take it out of the box for strategy planning. because i would imagine that the pwms could get plugged in incorrectly and fry the screen :(

biojae 12-08-2009 18:45
Re: Driver Station Usb
 
The Pwm cords go to the driverstation, the serial port to the screen

(and i just noticed how far away from USB I've gotten, the title is definatly incorrect)

The parts are definatly shipped :D


All times are GMT -5. The time now is 02:41.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi