|
|
|
![]() |
|
|||||||
|
||||||||
shows the in and out pins from the drivers station to the arduino touch screen, the path is not sent directly to the robot, only as a visual suggestion to the path the robot might take. only the vertices of the lines are sent, at a max of 50 (limit so that all points could be sent at the last second, if required)
http://www.chiefdelphi.com/forums/showthread.php?t=77903
09-08-2009 16:47
Jared Russell
This looks like a great and interesting idea, however I would urge caution about designing to the 2009 Driver Station interface specifically. Given some of its problems this year, and Bill Miller's statement that a Classmates PC would be in next years' kit, there may be different if not easier ways to interface in the future.
09-08-2009 17:11
Chris is meWould you be able to use the touch screen to map a waypoint based autonomous mode on the fly? Because there were multiple times where I would have loved that (mostly while "breaking" air lock loading auto modes from the likes of 1114).
09-08-2009 17:31
biojae
|
Would you be able to use the touch screen to map a waypoint based autonomous mode on the fly? Because there were multiple times where I would have loved that (mostly while "breaking" air lock loading auto modes from the likes of 1114).
|
| This looks like a great and interesting idea, however I would urge caution about designing to the 2009 Driver Station interface specifically. Given some of its problems this year, and Bill Miller's statement that a Classmates PC would be in next years' kit, there may be different if not easier ways to interface in the future. |
09-08-2009 18:53
biojae
but, the points have to be entered before the robot is enabled, so a limit of 50 points is imposed. 50 because the driverstation updates at 50hz and it would only take 1 sec. best case.
The points are sent in order received on the screen,
and if they aren’t inputted fast enough the last points may not be received.
so a memory will be implemented on the screen (as it has its own processor),
and on the next power up, act like the points were inputted from a person, but much faster
09-08-2009 18:58
RyanCahoon|
The points are sent in order received on the screen,
and if they aren’t inputted fast enough the last points may not be received. |
09-08-2009 19:06
biojae
|
Why not just resend the points every second? The point number input would always tell which point is being sent so why not 1, 2, 3, ..., 49, 50, 1, 2, ... ?
--Ryan |

09-08-2009 19:26
Jared Russell
This discussion brings up an interesting rules question.
Presently, you can download code to a robot when it is on the field by plugging your laptop into the other Ethernet port. Doing a soft reboot would then complete the update. A few times this year we have done so to get in "last minute" code changes without having to tether up the bot in the queuing line.
However, if properly written, one could eliminate the need to reboot the robot altogether. Here's what I'm thinking:
1. Create your autonomous mode on the laptop.
2. The software then creates a text file representing the sequence of autonomous commands.
3. The laptop is connected to the driver station Ethernet port.
4. Using FTP, the text file is placed on the cRIO.
5. Upon the initialization of autonomous mode, the software parses the text file and acts upon the stored sequence of commands.
As long as all of these steps are complete by the time the robot is enabled, is there anything in 2009 (or past) rules that would preclude this scheme? As far as I am concerned, this solution is far easier than using an Arduino board and writing a custom communications protocol.
I think I have some coding to do.
(Even if the 2010 rules explicitly disallow transmission of packets from a laptop to the cRIO at any point when the robot is on the field, such a scheme would probably still be the easiest way to tweak autonomous modes without ever needing to rebuild or even reboot)
09-08-2009 20:06
Billfred
I can't think of any 2009 rules that prohibits FTPing a file of commands over pre-match. 195 used a similar strategy in 2006 to let them create waypoints to make them more effective in defending against opponents in autonomous (theirs, as I remember, used a PDA connected to the serial port to dump the data before the match).
I'll ask a silly question: What if you want to run your manipulator (including specifying a particular position) during your autonomous routine?
09-08-2009 20:59
biojae
|
I'll ask a silly question: What if you want to run your manipulator (including specifying a particular position) during your autonomous routine?
|
10-08-2009 00:32
biojae
|
Presently, you can download code to a robot when it is on the field by plugging your laptop into the other Ethernet port.
|
10-08-2009 12:26
Elgin Clock
Wasn't the concept of this introduced in Atlanta during the Championship Event on the big screen in 2008 when the cRIO was first officially & publicly announced?
What ever happened to that?
As a person with a CAD background, it seemed really cool to just draw a path & have a robot follow that.
Never saw anyone use anything like that this year though.
So disappointing.
Hopefully in the future more people will attempt this & succeed.
10-08-2009 19:54
biojae
|
Wasn't the concept of this introduced in Atlanta during the Championship Event on the big screen in 2008 when the cRIO was first officially & publicly announced?
What ever happened to that? As a person with a CAD background, it seemed really cool to just draw a path & have a robot follow that. Never saw anyone use anything like that this year though. So disappointing. Hopefully in the future more people will attempt this & succeed. |
).
14-08-2009 00:47
biojae
This is similar to what it is going to look like

14-08-2009 00:48
Akash RastogiDid you model this yourself or did you find it somewhere?
14-08-2009 00:58
biojae
25-08-2009 23:33
biojae
Today, the touchscreen finally arrived
The circuit is almost completely soldered, and the screen can be powered off of one IO pin on the DS
Pictures soon, waiting for a photo box
*Heads off to go programming
*