pic: Thousands of manhours of work... coming '07

[Matt Krass]

Originally Posted by Tom Bottiglieri

Looks good. I'm wondering how you're going to get "Drive Forward 100 inches" to actually work on the robot hardware side. Some modular drive control functions on the IFI side, perhaps?

We did something similar last year, but it was all done on the IFI hardware. I like bringing it off of the RC though; we ran into some interrupt problems between the encoders, timers, and constant serial traffic between the RC and our LCD screen system.

Serial traffic alone is building up trouble, we're overflowing buffers a lot, so we may have to minimize the amount of data available. I think the IFI serial port system just wants to make people cry

What kind of LCD system did you use? We're looking in to adding that functionality, if its worthy of the extra wiring and code and presents a useful advantage.

[Tom Bottiglieri]

Originally Posted by Matt Krass

What kind of LCD system did you use? We're looking in to adding that functionality, if its worthy of the extra wiring and code and presents a useful advantage.

We were able to tap into our available TTL serial port on the RC last year to drive a serial-driven LCD. It was a 4x20 character display, and was very useful for diagnostics and PID loop tuning. We could test the robot and use the screen as a pseudo terminal to test functions of the robot without a laptop.

We created a menu system which made configuring the robot like using a copy machine. You could use up and down buttons to change the menu options, and select/back to advance through the sub menus.

The real glory in our system was in the pocket PC based waypoint creator. Make the waypoints on the PPC, plug in the serial cable, and it automatically synced. Cool stuff.

[Matt Krass]

Originally Posted by Tom Bottiglieri

We were able to tap into our available TTL serial port on the RC last year to drive a serial-driven LCD. It was a 4x20 character display, and was very useful for diagnostics and PID loop tuning. We could test the robot and use the screen as a pseudo terminal to test functions of the robot without a laptop.

We created a menu system which made configuring the robot like using a copy machine. You could use up and down buttons to change the menu options, and select/back to advance through the sub menus.

The real glory in our system was in the pocket PC based waypoint creator. Make the waypoints on the PPC, plug in the serial cable, and it automatically synced. Cool stuff.

Didn't use a camera last year?
We were looking at using TTL port for simplicity in hardware (no level shifters) but we want to include a passthrough to make the camera an option alongside the black box.

[magical hands]

No offense guys, I believe we implemented a very similar system last year[1219 Iron Eagles]. We implemented 6 sensors on our robot with a navigation system. We had ours hooked up to a tablet PC, so we select points on the tablet and the action to perform and it writes a code into C and loads into the robot. We created sectors in EEPROM so basically we can save like 6 to 9 different codes in EEPROM and than based on the binary switches [coded for example 001 - autonomous 1] we were able to change our autonomous. We didn't find lot of success last year because our microcontroller broke in one of the game and so we had to literally re-design the control system. Hopefully we can use it this year

[Mike]

Originally Posted by magical hands

No offense guys, I believe we implemented a very similar system last year[1219 Iron Eagles]. We implemented 6 sensors on our robot with a navigation system. We had ours hooked up to a tablet PC, so we select points on the tablet and the action to perform and it writes a code into C and loads into the robot. We created sectors in EEPROM so basically we can save like 6 to 9 different codes in EEPROM and than based on the binary switches [coded for example 001 - autonomous 1] we were able to change our autonomous. We didn't find lot of success last year because our microcontroller broke in one of the game and so we had to literally re-design the control system. Hopefully we can use it this year

6 sensors?

What type of off board processor were you guys using?(you mention microcontroller so I figured it was something other than IFI)

[Donut]

Originally Posted by Mike

6 sensors?

Six limit switches aren't that bad to program, are they?

This sounds interesting as a "leveling the playing field" option for autonomous modes. I'm not sure how bad that price tag is though; I'll have to see what sensors are included with that before I get really excited over this.

[Mike]

Originally Posted by Donut

Six limit switches aren't that bad to program, are they?

This sounds interesting as a "leveling the playing field" option for autonomous modes. I'm not sure how bad that price tag is though; I'll have to see what sensors are included with that before I get really excited over this.

Haha I guess not

Now that I think about it, the $300 cost included development tools (which you wouldn't need, unless you really wanted to play around). The actual cost for a team that would just use our firmware would be under $225. The development board we use (STK500) is about $80. Since the source code will be freely available the more technical-minded teams might be more inclined to purchase their own devel board. A cheap AVR programmer could be made for $10 in parts, but the STK really is the best solution.

Also note that we won't be re-selling the parts. As of now a parts list will be available, with detailed assembly instructions. Therefore there is no overhead.

EDIT: The more I think about it, we could probably design this to accomodate cheaper components. The current price tag includes decently high resolution items, so it might be possible to make it more economically viable. We'd have to see what the price/performance tradeoff is.

[Matt Krass]

Alright let's clear one thing up. This won't be a black box unless you want to completely disregard the included documentation. The whole device will most likely be released in the form of schematics, source code, and documentation on the protocol and wiring, as well as comments in the code. All the programming on our side is handled with freely available open source tools that even come with a windows installer. So it'll be pretty easy for teams to modify it to work for them if they wish, but we're hoping the default set up will be useful for most teams.

I'm also wondering if teams would be interested in a menu-driven 4 line by 20 character LCD for set up, calibration and possibly "instant feedback" of the robots status (Tach and such) similar to what Tom described for 195s system. This has to be designed in due to the nature of the LCDs control system. Hopefully it won't drive the price up a whole lot either.

So what's the word on that?

[Billfred]

Originally Posted by Matt Krass

I'm also wondering if teams would be interested in a menu-driven 4 line by 20 character LCD for set up, calibration and possibly "instant feedback" of the robots status (Tach and such) similar to what Tom described for 195s system. This has to be designed in due to the nature of the LCDs control system. Hopefully it won't drive the price up a whole lot either.

So what's the word on that?

As awesome as it sounds, it kinda feels like a bell and/or whistle (though I've never used one on a robot, so I could be dead wrong). How hard would it be for someone to integrate the LCD control code in with the existing code, assuming they have both?

[chris31]

Originally Posted by Billfred

As awesome as it sounds, it kinda feels like a bell and/or whistle (though I've never used one on a robot, so I could be dead wrong). How hard would it be for someone to integrate the LCD control code in with the existing code, assuming they have both?

It wouldnt be to hard since they already have a development board set up and it probably has extra pins that they could use to run an LCD screen.

[Mike]

Originally Posted by Billfred

As awesome as it sounds, it kinda feels like a bell and/or whistle (though I've never used one on a robot, so I could be dead wrong). How hard would it be for someone to integrate the LCD control code in with the existing code, assuming they have both?

Matt and I discussed this point of view last night (errr... this morning) and came to the conclusion that it should be possible to have a bare bones version of this system. This would be geared towards teams with a lower budget and includes parts such as lower resolution sensors, no LCD, etc. However the hardware side of this is designed such that if you ever want to upgrade, its a matter of a few code modifications and attaching the new module to an expansion port.

So for those that don't want the LCD, no problem. For those that do, the option is there for you.

What we are trying to do with navigation systems is analogous to what Kevin Watson did for the camera. In 2005 only the most technically adapt teams had cameras, with the release of Kevin's code in 2006 I'd say with confidence that 1/3 teams had cameras.

We want to level the playing field. With our system, its not about who has the most resources and ability to build a navigation system, but who has the most strategy and innovation to use that navigation system. It gives rookie teams the same opportunity as vets.

[Matt Krass]

Originally Posted by Billfred

As awesome as it sounds, it kinda feels like a bell and/or whistle (though I've never used one on a robot, so I could be dead wrong). How hard would it be for someone to integrate the LCD control code in with the existing code, assuming they have both?

Well so far we're doing pretty good on memory constraints, so its pretty easy to just leave the LCD code there and if there's no LCD, you ignore it. We're looking in to making all the available I/O pins available on headers externally accessible, but protected against damage, for future "upgrades" and expansion.

Our goal is for Team X to get the base unit, set it up, and find it so useful they want the feedback LCD, so they get one of those, plug it in and power cycle the device. The box will detect an LCD and initialize it, and it's done. At worst, they may need to connect a serial cable and do a firmware update we provide. At the same time, all of the wiring and programming is available for they're modification if they want, and documented.

Originally Posted by chris31

It wouldnt be to hard since they already have a development board set up and it probably has extra pins that they could use to run an LCD screen.

I'm already working on an LCD display driver and library of code on an identical dev board in my workshop. It's working quite well and I'm re-implementing a simplified printf for it. It's actually a pretty easy hook up.

[Andrew Blair]

Well, great generosity in FIRST again! Great work guys, but if you release it this year, I won't have a reason to code the "Destroy autonomous juggernaut"
program! That's about the limit of my coding ability anyways...

voidDESTROY(void)
{
pwm04=pwm05=255;
}

Haha, now I'm curious about what sensors you've included in the setup. I saw two encoders on the practice robot, but I always thought it'd be easier to use a gyro and one encoder. What hardware are we looking at needing?

[Matt Krass]

Originally Posted by Andrew Blair

Haha, now I'm curious about what sensors you've included in the setup. I saw two encoders on the practice robot, but I always thought it'd be easier to use a gyro and one encoder. What hardware are we looking at needing?

The test setup we're using is one gyroscope, two encoders. While we could get away with one encoder, the added information opens up a bunch of doors. Since we're passing on both robots field position and heading as well as raw sensor data, you can use it for other stuff as well. The overheard for an extra encoder is minimal since we're offboard, so it's good to have the extra information. Plus it improves accuracy, which is a big concern considering the large number of possible calibrations for different drivetrains we have to deal with.

[Barry Bonzack]

If we are unable to use code created before the six weeks in a copy/paste action as discussed here, how would that that rule apply to generating code from a program that was written with hundreds of hours before the six weeks?