View Full Version : pic: Thousands of manhours of work... coming '07
[cdm-description=photo]26078[/cdm-description]
RoboMadi
24-12-2006, 14:49
ehm...........what is this?
Does look like a drive train to me....
Robot Balboa?:p
Imad
Tim Arnold
24-12-2006, 14:53
Sounds interesting, but I can't help to chuckle when I look at the portal and this on the side... No More Teasers in 2007! (http://www.chiefdelphi.com/forums/showthread.php?threadid=50698)
Tom Bottiglieri
24-12-2006, 14:53
Looks like Mike got his navigation black box working. Lets see if its useful.
As a little side note:
All schematics, code, part numbers, EVERYTHING from this project will eventually be released. For under $300 and some basic technical know-how (eg: can you read an instruction manual?), a first year team will be able to implement a very accurate and effective...
Wait, what were we talking about again? ;)
Billfred
24-12-2006, 15:23
Man, that is an exquisite box of Diet Pepsi. ;)
Now, out with the details--judging from the picture and the poster, I assume it's some software kung-fu (and world-class kung-fu at that, knowing 237's track record with such things). Color me interested.
Looks like Mike got his navigation black box working. Lets see if its useful.
Is that what the extra board is.
From Mikes post it looks like he is using that board to read the values that would be send over the dashboard port. I assume he is parseing them and logging them to something a CF card maybe. You can then use that log in making your autonomous code. It looks very nice.
Andrew Blair
24-12-2006, 23:00
Looks like Mike got his navigation black box working. Lets see if its useful.
Alright! I can see two encoders; I imagine you coupled it with a gyro, maybe an accelerometer for wheel slip if you wanted to get really fancy (4 Thousand lines!?! Where does it all go!)? Maybe even a nice input system to easily code a coordinate autonomous, perhaps even on the fly?
If you are doing the black box as Tom stated, I'm impressed. I had started to think about it a couple years back, but never had the initiative or skill to code it. And I'm glad I didn't try! Four thousand lines and change? Crazy, but awesome. Don't feel pressured to release that baby, especially not this coming year. You deserve the exclusive right to an insane autonomous if you created it!
Maybe even a nice input system
http://img72.imageshack.us/img72/9826/untitled2ug9.jpg
I think I should stop talking now :D
Matt Krass
24-12-2006, 23:59
Looks like Mike got his navigation black box working. Lets see if its useful.
Hey, I programmed that black box ;)
Actually Mike and I are working on this together, its a fun project and so far, its mostly operational, the RC is being a bit uncooperative though.
Is that what the extra board is.
That's an STK500 In-System Programmer and prototype board from Atmel, it's the (temporary) home of our blackbox, which monitors the robot and sends a nice packetized burst of information to the RC with all kinds of useful info :)
Heretic121
25-12-2006, 00:02
from tom's comment i cant help to think what havoc this might bring upon with another "black box" like 195 had last year...
Sounds like fun! I'm glad to know there'll be some impressive autonomous modes out there this coming year. We have to see the results you get from this next season, I hope it proves that sensors really can make such a huge difference.
We'll try to give you a run for your money if we can.
http://img72.imageshack.us/img72/9826/untitled2ug9.jpg
I think I should stop talking now :D
I had never seen this or heard about it before until now. Honestly.
But this is the "exact, identical, ditto" IDEA that I had for this year.
But I am no where near where you guys are with it. I am currently working with external PICs and Visual C++ app programming.
Honestly, I have never seen or heard about this before today yet the idea started this summer. That picture is exactly what it was.
I dought, I will be able to get it done though.
Good luck to you guys.
I forgot I mentioned this project to Tom a while back, seems like the majority of the mystery is gone. Should've known not to trust him with stuff like this :p
Don't think I'm gonna let you in on all the juicy stuff...
This is a joint effort between Matt Krass and I. The testbot and hardware is located at my house, but without him this project would've never advanced from an idea and sketch on paper. He provided a large amount of the technical information that I didn't know prior to this project. Biggest learning experience of my life.
So heres a brief run-down.
ATMega16
STK500
No dashboard port
CF card? Don't give me ideas...
Havocs a nice word
$300 and an hour or two of work and you're up and runningThat is all ;)
Tom Bottiglieri
25-12-2006, 01:09
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.
Matt Krass
26-12-2006, 15:59
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
26-12-2006, 16:14
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
27-12-2006, 03:06
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
27-12-2006, 20:56
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 ;)
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? :ahh:
What type of off board processor were you guys using?(you mention microcontroller so I figured it was something other than IFI)
6 sensors? :ahh:
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.
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 :P
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
28-12-2006, 01:21
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
28-12-2006, 09:31
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?
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.
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
28-12-2006, 16:07
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.
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
28-12-2006, 20:28
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
28-12-2006, 20:47
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
29-12-2006, 17:26
If we are unable to use code created before the six weeks in a copy/paste action as discussed here (http://www.chiefdelphi.com/forums/showthread.php?t=50240&highlight=program+rule), how would that that rule apply to generating code from a program that was written with hundreds of hours before the six weeks?
Greg Marra
29-12-2006, 17:32
If we are unable to use code created before the six weeks in a copy/paste action as discussed here (http://www.chiefdelphi.com/forums/showthread.php?t=50240&highlight=program+rule), how would that that rule apply to generating code from a program that was written with hundreds of hours before the six weeks?
I'd imagine it lies somewhere along the lines of using the default code that Kevin Watson provides. Tons of teams implemented the camera code he wrote for last year's game, but a quick glance through the comments reveals it was written well in advance of build season.
If we are unable to use code created before the six weeks in a copy/paste action as discussed here (http://www.chiefdelphi.com/forums/showthread.php?t=50240&highlight=program+rule), how would that that rule apply to generating code from a program that was written with hundreds of hours before the six weeks?
On top of what Greg said here is another point. The code for the robot itself isnt generated before the 6 weeks. Just the code for a tool. From my understanding its just a development tool. It wount be on the robot during competition. So it no diffrent that say getting a screwdriver before the season (yes i know its an abstract thing). Its just a tool and no reason you cant work on a tool before the season.
Matt Krass
30-12-2006, 02:49
We're not providing any control code, or anything to make a robot function, just code to retrieve information from a device, it's no different than the code IFI provides to retrieve analog info from the ADCs, or the code Kevin provides to retrieve information from the camera. It doesn't "do" anything, like move the robot, or shoot a ball, so we feel it's not in violation of the rules.
Andrew Blair
30-12-2006, 09:38
I think what needs to be recognized here is the spirit of the rule, and not the wording. This is intended, like Kevin's code, to be a free, openly available tool that has been developed to increase the capability, and improve the learning curve of new, or limited resource teams. And, when it comes to software, most teams have limited resources.
magical hands
30-12-2006, 14:55
Hi! Guys as I mentioned before that I did a similar project. When I was doing this, I found that the most expensive part of this project is LCD itself. If you have a smal LCD Panel than you first need to create a cross-platform between a C language and the language required to program the LCD panel itself. Also, if it is a small screen which costs about I don't know around $50? Is not going to help a lot since you can't display a lot of information. What I would suggest is if you guys can do something what we did last year. We used table PC but you guys can use laptop also if no one on team has tablet. Have the COM Port on laptop communicate with the control system in real time so you always have the information such as co-ordinate values, velocity, sensor values, motor values, current flow in robot and etc monitored at all the times. If you guys don't want to do lot of hard work than their is always IFI dashboard we can use. But I would say this would be a challenge. ;)
Hi! Guys as I mentioned before that I did a similar project. When I was doing this, I found that the most expensive part of this project is LCD itself. If you have a smal LCD Panel than you first need to create a cross-platform between a C language and the language required to program the LCD panel itself. Also, if it is a small screen which costs about I don't know around $50? Is not going to help a lot since you can't display a lot of information. What I would suggest is if you guys can do something what we did last year. We used table PC but you guys can use laptop also if no one on team has tablet. Have the COM Port on laptop communicate with the control system in real time so you always have the information such as co-ordinate values, velocity, sensor values, motor values, current flow in robot and etc monitored at all the times. If you guys don't want to do lot of hard work than their is always IFI dashboard we can use. But I would say this would be a challenge. ;)
I think they are planning on using like a 2x20 character screen ($20) to save money enstead of on an OLED screen. But i could be wrong. An OLED could be really cool.
Matt Krass
30-12-2006, 15:43
We don't actually know what we're going to use yet, that's why we want your feedback! The LCD module will be an expansion, so if teams don't want it, they can skip, or maybe get a smaller one for less cost, but to offer options we need to know which you want, so keep this stuff coming, it's good stuff :)
We don't actually know what we're going to use yet, that's why we want your feedback! The LCD module will be an expansion, so if teams don't want it, they can skip, or maybe get a smaller one for less cost, but to offer options we need to know which you want, so keep this stuff coming, it's good stuff :)
I want 2 x 6 inch color touch screens. One to show camera tracking and the other for other info. :p
On a serius note, I am trying to get the parts together, but I would like to get a small screen outputing camera info. Both for coolness and debugging. This (http://www.sparkfun.com/commerce/product_info.php?products_id=569#) screen looks like a very good option for you. One $20, not to heard to interface and some example AVR code already written.
We don't actually know what we're going to use yet, that's why we want your feedback! The LCD module will be an expansion, so if teams don't want it, they can skip, or maybe get a smaller one for less cost, but to offer options we need to know which you want, so keep this stuff coming, it's good stuff :)
I think a regular 4x20 would be great. They are easy to get and fairly cheap.
I'm also curious about the possability of using graphic LCD modules...something like this http://www.crystalfontz.com/products/160128b/index.html#CFAG160128BYYHTZ
I think a regular 4x20 would be great. They are easy to get and fairly cheap.
I'm also curious about the possability of using graphic LCD modules...something like this http://www.crystalfontz.com/products/160128b/index.html#CFAG160128BYYHTZ
Cool, but ouch. $76 :(
Oh the possiblities. So mcuh cool stuff and info you could display on that.
Andrew Blair
30-12-2006, 22:20
Alot of teams are used to SparkFun, but you could probably do better price wise.
20x4 LCD with Backlight (http://www.sparkfun.com/commerce/product_info.php?products_id=256)
Matt Krass
30-12-2006, 22:30
That's the kind of LCD we were looking it.
Question, does anyone think they'd be interested in a button controlled UI or just having a fixed output screen on the LCD showing certain things?
That's the kind of LCD we were looking it.
Question, does anyone think they'd be interested in a button controlled UI or just having a fixed output screen on the LCD showing certain things?
Buttons would be nice. They dont have to be integrated onto the LCD board like some are. If you keep them separated you leave the ability to add more buttons later if you wish to for some reason.
Billfred
30-12-2006, 22:47
That's the kind of LCD we were looking it.
Question, does anyone think they'd be interested in a button controlled UI or just having a fixed output screen on the LCD showing certain things?If I'm gonna go so far to implement an LCD on the robot, I'd go whole-hog on it with the buttons.
Matt Krass
31-12-2006, 01:49
Well folks, we seem to have generated quite a buzz here, and it's about to get louder. This mysterious device, all you know is its a navigation system and it's designed to be easy to use. But is it really easy to use? We think so, but the only way to know how easy it is to use, and how effective it is is to let teams try it. But it's not quite ready, it's working, but it's a bit messy, so we've decided to do a beta test.
We're looking for about 20 teams to disclose full drawings, full code, software, everything you need to build a prototype unit and use it on a competition robot. We're looking at a price point in the high 200s, due to the limited number of parts being ordered. Teams involved will have to be willing to try out new technology, and send us feedback. They will receive personal email support from the developers (Mike Sorrenti and I) as well.
We want to keep a small number of teams for a few reasons, mostly because support for a lot of teams is difficult, and we don't want the plans getting out until its been thoroughly bug-tested by some adventurous guinea--err beta-testers.
How much interest is there out there for a test group like this?
Tom Bottiglieri
31-12-2006, 02:12
How much interest is there out there for a test group like this?
Well Matt, I would love to take you up on your offer, but as always, I have yet another trick up my sleeve.:cool:
Upper 200s? Try 150. With a touchscreen.
See ya in 07!;)
Cody Carey
31-12-2006, 02:43
Team 306 would definitely be interested in beta testing this...
If we are unable to use code created before the six weeks in a copy/paste action as discussed here (http://www.chiefdelphi.com/forums/showthread.php?t=50240&highlight=program+rule), how would that that rule apply to generating code from a program that was written with hundreds of hours before the six weeks?
This is a mistaken assumption. The thread you linked discusses R71, which deals with limitations on using code from the robots of previous years.
<R71> Unaltered software modules developed during prior competitions may not be directly re-used. Just as designs for hardware COMPONENTS may be reused from one year to the next, software algorithms and designs may be reused. However, the specific lines of code must be customized for each robot each year.
Noticed the bolded text. This rule prevents a team from using identical blocks of code from prior years. It does not prevent a team from using code developed outside of the competition. Code like Kevin Watson's or what Mike and Matt have developed is legal according to my interpretation of the 2006 rules.
Of course, the rules on this topic may change for 2007. We'll find out in a few days.
Billfred
31-12-2006, 08:15
Well Matt, I would love to take you up on your offer, but as always, I have yet another trick up my sleeve.:cool:
Upper 200s? Try 150. With a touchscreen.
See ya in 07!;)I'll have what he's having!
Seriously, though, I'd be interested in pitching this to the team if the game looks to call for it. A more complex autonomous, like in 2003, 2004, and some in 2006, would make me strongly in favor of implementing the system. But if we're just knocking off the hanging tetra, then I just can't quite justify it for this season. Ask me after Kickoff.
Matt, Team 2021 is willing to help beta test it for you.
magical hands
31-12-2006, 14:01
I know how you guys said you want 2 X 20 or 4X20 LCD screens but I don't think you guys can get what you want. Here is why, you don't have lot of character options and I know how you wanted feedback from camera but what kind of feedback? A simple text based saying "Colour Green Detected" "Distance 45 meters"? or something that shows you what the camera is viewing, in other words looking from camera's point of view.
Also, With a small 2X20 LCD screen how are you guys planning on creating a navigation system. Especially the interface? I thought you guys have a GUI that goes along with your navigation system. In such circumstance you guys will be using a laptop to map the co-ordinates and than the GUI will generate a code based on co-ordinates you selected and than feed info to micro-controller. Well why go through so much trouble?
Have an embedded computer into your control system, which you can use to run your GUI while designing autonomous. Once you are done designing autonomous you can have options to save 9 different autonomous modes into EEPROM. During the autonomous have an onboard binary swtich system which will allow you to activate one of the 9 autonomous from EEPROM. At the same time you can use your computer that is embedded to get realtime feedback from the robot during a game.
-:::-Jigar Patel [1219 IRON EAGLES]-:::-
magical hands
31-12-2006, 14:34
:D ;)
I know how you guys said you want 2 X 20 or 4X20 LCD screens but I don't think you guys can get what you want. Here is why, you don't have lot of character options and I know how you wanted feedback from camera but what kind of feedback? A simple text based saying "Colour Green Detected" "Distance 45 meters"? or something that shows you what the camera is viewing, in other words looking from camera's point of view.
Matt and I never mentioned camera data.
Also, With a small 2X20 LCD screen how are you guys planning on creating a navigation system. Especially the interface? I thought you guys have a GUI that goes along with your navigation system. In such circumstance you guys will be using a laptop to map the co-ordinates and than the GUI will generate a code based on co-ordinates you selected and than feed info to micro-controller. Well why go through so much trouble?
Would you rather be required to pay $XXX more in order to purchase a PDA to attach to the bot?
Have an embedded computer into your control system, which you can use to run your GUI while designing autonomous. Once you are done designing autonomous you can have options to save 9 different autonomous modes into EEPROM. During the autonomous have an onboard binary swtich system which will allow you to activate one of the 9 autonomous from EEPROM. At the same time you can use your computer that is embedded to get realtime feedback from the robot during a game.
-:::-Jigar Patel [1219 IRON EAGLES]-:::-
$200 price limit. Why have binary switches if we already have a fully loaded/embedded computer? If the computer is on the robot, how are we supposed to see the information in realtime?
Tom, is your system plug and play? :cool:
Andrew Blair
31-12-2006, 15:40
I have a question regarding your plug and play setup. I assume the gyro and encoders are plugged into the dev. board, and you just supply power and a serial connection to the brain, right?
I have a question regarding your plug and play setup. I assume the gyro and encoders are plugged into the dev. board, and you just supply power and a serial connection to the brain, right?
Now that I think about it maybe have support for serveral diffrent gyros and encoders so it would be mor eplug and play.
@magical hands: I dont think there was ever a plan to output camera info to a character lcd. Maybe to a larger oled or soemthing but not a character lcd.
Tom Bottiglieri
31-12-2006, 15:48
Tom, is your system plug and play? :cool:
Bill,
Quality over quanity.
Sincerely,
Linus
Matt Krass
31-12-2006, 15:52
I have a question regarding your plug and play setup. I assume the gyro and encoders are plugged into the dev. board, and you just supply power and a serial connection to the brain, right?
Our board will house all the sensor connections, and power, and a serial cable goes to the program port.
One misconception I'd like to clear up is the kind of data this will make available. Besides passing on raw sensor data, it will also pass on an X/Y coordinate and heading value to the robot. This allows an out of the box user to immediately have a wealth of info it takes most teams a few weeks to get to. Also, we are looking in to writing and releasing code after kickoff that will illustrate waypoint based driving and an autonomous state machine. We are also playing with the idea of an auto-calibration system to make user set up even easier.
EDIT: I wanted to add this. Once calibrated, the system will work any gyro/encoder system you use, with varying degrees of accuracy depending on the sensors used. Higher count encoders will be more accurate, lower count will be less. Higher/lower quality gyros can have a same effect. But fundamentally the code is designed to be sensor-independent, with all the variance accounted for in the initial calibration.
Thanks for the input all,
We'd like to bring this topic back into focus. The competing systems are an interesting discussion, and will be a fun topic once the full capabilities of both are revealed. Matt and I are confident in what we have developed, and are looking for others to invest in that confidence.
So, who would be willing to beta test?
Tom Bottiglieri
31-12-2006, 16:07
For possible system beta testers:
Take everything I've said in this thread with a grain of salt. My INS is still in early stages of the design process, and I have no intention of making it public in the 2007 season.
So, beta test away. I believe all you need is encoders on each drive side, a gyro, and the AVR board. You'll probably get a gyro and gear tooth sensors in the kit, so maybe you'll just need the AVR board.
Rob2713g
31-12-2006, 16:08
I have to confirm when my team meets on Wednesday, but those that I have spoken to on Team 540 are interested and want to do it. We will also ask 384 and 1086 - who we are working with to share resources.
Billfred
31-12-2006, 16:19
Other question of interest to me: Is this system adaptable to some of the growing numbers of omnidirectional robots? Even in such a grunt-heavy game as Aim High, you still saw a small number of teams take it sideways in various forms--and interest in them seems to be pretty high, going by the number of CAD drawings and prototypes I've seen on ChiefDelphi.
Thanks for the input all,
We'd like to bring this topic back into focus. The competing systems are an interesting discussion, and will be a fun topic once the full capabilities of both are revealed. Matt and I are confident in what we have developed, and are looking for others to invest in that confidence.
So, who would be willing to beta test?
Im willing, I have to check with the team though. Any idea on when schematics and all will be posted since kickoff is just around the corner.
Other question of interest to me: Is this system adaptable to some of the growing numbers of omnidirectional robots? Even in such a grunt-heavy game as Aim High, you still saw a small number of teams take it sideways in various forms--and interest in them seems to be pretty high, going by the number of CAD drawings and prototypes I've seen on ChiefDelphi.
The current revision is designed to work on robots based on the typical (and currently dominant) drive systems.
The next version (not this season) will be able to handle any type of drive system, however. As of now, our mantra is "Jack of all trades, master of none."
Im willing, I have to check with the team though. Any idea on when schematics and all will be posted since kickoff is just around the corner.
Our time schedule estimates that beta testers will receive full plans and schematics some time before the end of Week 1. However, they will be given all the information we currently have ASAP. For the amount of work that you could get done by week one, the current information is more then plenty.
Adam Richards
31-12-2006, 16:35
Thanks for the input all,
We'd like to bring this topic back into focus. The competing systems are an interesting discussion, and will be a fun topic once the full capabilities of both are revealed. Matt and I are confident in what we have developed, and are looking for others to invest in that confidence.
So, who would be willing to beta test?As long as you can get me the schematics in week 1, I should be more than able to get my team to assist. I'll just need to talk to the programming mentor and programming lead first.
Matt Krass
31-12-2006, 16:56
We appreciate the feedback and interest you've all displayed. We're working to get the beta test approved and your interest is very helpful, please keep it coming. Once it's all squared away and the beta is approved we'll release the official beta details and start emailing invites.
magical hands
31-12-2006, 17:09
Hey you guys can surely add 1219 to your beta test. We would love to try that control system and help give as much feed back possible :) If you guys want you can contact team 1219 on following e-mail jigarjuhi [at] yahoo dot ca
Couple of questions though! Are we allowed to modify your control system to suit our robot? for example your control system might be designed for 4 wheel drive but what if we have 6 wheel drive?
Also, if team chooses to implement your control system but what if later on they choose not to use it? is that fine? or you have to stick to the plan?
-:::-Jigar Patel [1219]-:::-
magical hands
31-12-2006, 17:19
Matt and I never mentioned camera data.
Not you but some other people on the post mentioned so I assumed you guys have that feature.
Would you rather be required to pay $XXX more in order to purchase a PDA to attach to the bot?
You don't necessarily have to purchase a PDA, I am 110% sure every team has atleast 1 laptop in pit area. Why not make better use of that laptop and have it embedded on control system. Now you can do your programming as well as use it as an onboard computer.
$200 price limit. Why have binary switches if we already have a fully loaded/embedded computer? If the computer is on the robot, how are we supposed to see the information in realtime?
Why Binary swtiches? When you are in autonomous mode you are running an autonomous(); That means you are not linked to anything not even radio control so you can't communicate. In such situations you do need something onto the robot such as "Binary Switches" to tell your Autonomous(); what to do when certain switches are on and off. Correct me if I miunderstood the concept please because certainly I could be wrong.
Tom, is your system plug and play? :cool:
Yes our system is plug and play
Billfred
31-12-2006, 17:21
The current revision is designed to work on robots based on the typical (and currently dominant) drive systems.
Makes perfect sense to me.
I'll have to do some checking before committing, but this certainly sounds interesting.
Greg Marra
31-12-2006, 17:31
You don't necessarily have to purchase a PDA, I am 110% sure every team has atleast 1 laptop in pit area. Why not make better use of that laptop and have it embedded on control system. Now you can do your programming as well as use it as an onboard computer.
Computers + high speed impacts = :(
magical hands
31-12-2006, 18:45
Computers + high speed impacts = :(
Don't get me wrong but I didn't mean onboard meaning on robot. I meant it on control system lol :) Was my assumption correct or you meant something else?:confused:
Greg Marra
31-12-2006, 20:28
Don't get me wrong but I didn't mean onboard meaning on robot. I meant it on control system lol :) Was my assumption correct or you meant something else?:confused:
Oh I understand what you mean now. You will use the laptop as a combination dashboard -slash- program-the-autonomous-mode-with computer.
177 used a dashboard with great effect last year. I highly recommend them. It gave us very good diagnostic information and let us check out all the key parts on our system with a single glance at the screen.
Andrew Blair
01-01-2007, 00:39
Computers + high speed impacts = :(
Haha, frowny face indeed. As far as the LCD goes magical hands, I think it's just meant to be a really light, quick diagnostic device. Check modes, certain algorithm values (Such as PID), etc. Nothing big. If you are just using it for a relatively static auto. mode, then it is probably not even necessary. They do intend for it to be optional.
Tom Bottiglieri
01-01-2007, 02:31
Haha, frowny face indeed. As far as the LCD goes magical hands, I think it's just meant to be a really light, quick diagnostic device. Check modes, certain algorithm values (Such as PID), etc. Nothing big. If you are just using it for a relatively static auto. mode, then it is probably not even necessary. They do intend for it to be optional.
These are some things that flashed on the LCD when we started up last season:
Battery Voltage
Gyro Rate (to make sure it was calibrated correctly.)
Ultrasonic sensor distance (sometimes the plug came out and the distance was 0. We drove backwards...)
These things can be checked in another fashion, but in the heat of competition, its easy to miss something.
Greg Marra
01-01-2007, 02:34
These are some things that flashed on the LCD when we started up last season:
Battery Voltage
Gyro Rate (to make sure it was calibrated correctly.)
Ultrasonic sensor distance (sometimes the plug came out and the distance was 0. We drove backwards...)
These things can be checked in another fashion, but in the heat of competition, its easy to miss something.
177 used a dashboard for exactly the same purposes, and we caught some otherwise extremely serious problems before they lost us a match. I think I am smelling an episode of The Blue Alliance here...
How much work is the ATMega16 actually doing?
Matt Krass
01-01-2007, 23:04
It's handling trigonometry, ADC oversampling, interrupt counting, serial communications plus a few other things we're not quite ready to reveal :)
Overall I'd say we're utilizing 70% of the chips power and we're still looking in to a few more tricks.
I would be interested (1525).
Matt Krass
03-01-2007, 00:40
Unfortunately due to unforeseen constraints, we will be unable to run the beta test this build season. A lack of availability of parts and funds as well as technical difficulties prevent us from being able to fairly distribute the technology. However you will see updates from us as we develop it further. This also allows us the opportunity to add in a few planned features, such as the ability to use a second, lower-rate gyro (perhaps even the KoP gyro) to measure vertical tilt and account for travel up and down slopes.
Thanks for all your feedback, knowing you're interested makes us want to work that much harder.
A lack of availability of parts
A little more information on that, as I'm sure it is affecting many other teams right now:
Due to the EU RoHS directive, which took affect Jan 1, 2007, you more or less can not get the ADXRSxxxEB series gyro board. The 401 seems to be an exception, however the 80 degrees/second maximum isn't near the speed of an average FRC robot.
We are using the ADXRS300EB for development, and although we could more than likely find a currently RoHS compliant gyroscope, with the amount of time it would take for us to purchase and receive the gyro as well as modify all of our code/documentation it would be too tight of a squeeze.
Rest assured that when this is fully completed, it will be a great system.
Thanks for the understanding,
Mike
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.