Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Rumor Mill (http://www.chiefdelphi.com/forums/forumdisplay.php?f=15)
-   -   2009 Control System Possibility? (http://www.chiefdelphi.com/forums/showthread.php?t=66020)

ay2b 06-04-2008 20:15

Re: 2009 Control System Possibility?
 
Quote:

Originally Posted by Dave Scheck (Post 729127)
I definitely think that teams that have hybrid/autonomous robots that just sit there are doing so because of a lack of software understanding.

That may be the case for some teams, but I think more often than not it's due to insufficient time. When you only get the robot a few hours before it goes into the crate, in order to program it, it's usually considered more important to make it work in teleoperated mode, than in hybrid/autonomous mode.

Quote:

Originally Posted by Dave Scheck (Post 729127)
I think that the way that the game is defined will dictate the excitement of the autonomous movement (2005 wasn't very interesting was it?).

I agree with the game design dictating the excitement level, but I thought 2005 was very interesting. Our autonomous that year (after a few iterations doing other things) stacked a tetra on a goal, grabbed the hanging tetra (catching it mid-air), and then stacked it on top. 2004 had my favorite autonomous run - in one match we autonomously caught a ball mid-air as one team tried to beat us to it, and knock it out of our grasp - but 2005 was my overall favorite in terms of what we did and could do autonomously.

seanwitte 06-04-2008 20:45

Re: 2009 Control System Possibility?
 
Quote:

Originally Posted by erikstotle (Post 730943)
I whole-heartedly agree. Engineering is not about throwing together blocks of high-level code that "magically" works.

Actually, writing software for a living is primarily about doing just that. It's too expensive and time consuming to write everything from scratch. But this is FIRST, not real life. You're still at a point where you need to learn how all of this stuff works at the most basic level. I think the rules about code re-use need to be revised to allow teams to build up a body of knowledge and expertise over time. Your first year may be ugly, but each year after that should be better.

Going along with that, what about teams that choose not to invest resources to build up their programming expertise? A team without mechanical prowess can turn to AndyMark, but there is no source other that Kevin Watson for programming help. There are scattered whitepapers and forum posts, but no real tested and reusable code. A library of solid source code would be beneficial to everyone.

Jon236 06-04-2008 21:52

Re: 2009 Control System Possibility?
 
Quote:

Originally Posted by seanwitte (Post 731669)
Actually, writing software for a living is primarily about doing just that. It's too expensive and time consuming to write everything from scratch. But this is FIRST, not real life. You're still at a point where you need to learn how all of this stuff works at the most basic level. I think the rules about code re-use need to be revised to allow teams to build up a body of knowledge and expertise over time. Your first year may be ugly, but each year after that should be better.

Going along with that, what about teams that choose not to invest resources to build up their programming expertise? A team without mechanical prowess can turn to AndyMark, but there is no source other that Kevin Watson for programming help. There are scattered whitepapers and forum posts, but no real tested and reusable code. A library of solid source code would be beneficial to everyone.

Kevin's template provides a common base that enable's teams to have quadrature encoders and gyros running almost immediately, so you don't have to create everything from scratch. But how does a student understand how a gyro or an encoder works if they don't write and test the code themselves?

My programming training involves:

1. Having the kids read and understand Kevin's template to understand how the code works.
2. Teaching the basics of PID coding, switch debouncing and the like.
3. Trying to introduce behavior-based programming, to give the kids something to hang everything on.

Then I sit back and watch what they do. Sure I make suggestions and help them debug, but mostly I enjoy having them show me what they have done! They come away from the process with the self-confidence of having created a piece of code which makes the robot perform as they wish and the knowledge gained by doing the coding themselves. That is what FIRST is all about!

Danny Diaz 06-04-2008 22:17

Re: 2009 Control System Possibility?
 
Quote:

Originally Posted by Tim Skloss (Post 731153)
FIRST is about the students. As mentors we show them that engineering is hard but with disciplined and steady work it can be immensely rewarding. (If it were easy, where's the satisfaction??)

They are all winners the minute they decide to get serious and start contributing to the team's efforts. The competitions are their chance to celebrate what they have accomplished. Whether they end up with a simple, complex, broken or top-tier robot will make no difference.

Quote:

Originally Posted by Tim Skloss (Post 731155)
But isnt' that is one of the pillars of FIRST, at least according to Dean Kamen? FIRST requires the community of engineers to give back and inspire the next generation. The students need to see that we have an important impact on our society, and make a good living doing it. And those jobs are there for them.

Yep, Don't get me wrong, I agree with all these statements - except maybe the part about kids not caring if they have a crappy robot or not; everybody wants to have a successful robot, but I do agree that it's all about how you measure success - a rookie team measures success very much differently than a veteran team, but should that be the case?

I also agree that engineers should be giving back, but I had better not see:

Quote:

<R244> Each team shall have an engineer, or else they won't understand jack about what's going on.
In my mind, FIRST should have a competition that is accessible to kids, inspiring to kids, and FUN for kids. The engineers should be there to help those kids go farther, not for basic functionality. That's my opinion, at least. Just like there's a kit frame, there should be kit controls that are easy to use.

-Danny

tdlrali 06-04-2008 22:34

Re: 2009 Control System Possibility?
 
First of all, this thread contains some of the best discussions I've ever seen on Chief Delphi.

The two common viewpoints here seem to be either that a low-level system is better since students learn more or that high-level is better because it allows everyone to be more competitive.

How about a mix of the two? That's what we have right now - more experienced / advantageous teams can write everything in C (which is low-level enough), and the others can use easyC/WPILib.

Of course, neither option comes with complete control logic for everything, but the basic building blocks are there - we can use encoders, gyros and the like right out of the box (ok, small tweaks are often necessary). The argument that this is not enough is not valid. Software and hardware are very similar in this aspect: FIRST doesn't ship us a complete drive base that works right out of the box - they give us frame components, gear boxes and motors, and we can figure out what to do with it.

Continuing the hardware to software analogy, if all teams were given a full drive base, would that make FIRST better? In my opinion, it would not - it would take away from the design process and frankly, it would make the robots boring. Would we see swerve drives on the field if everyone was given a full drive base? Similarly, the fact that we are not given full software blocks makes FIRST more competitive.

Now, to get back to the actual topic, how would any hardware solution affect what the software can do? As long as FIRST leaves enough possibilities (aka, the choice of either using low(er)-level or high(er)-level programming), anything is possible. I don't think that FIRST should give us full software solutions to common problems, though. Coming up with those solutions is just as important of a lesson as finding solutions to mechanincal problems.

Lastly, the community has a huge influence over what is available to teams. I know that CD is always willing to help out people asking for help, but every team needs to be aware that this resource is available.

It would also be helpful to newer teams if the older teams stepped up and released some of their precious source code. I know everyone is proud of what they achieve and does not want to give it up to other teams since they want to keep the competitive edge, but if we want to make competitions more interesting, we need to give some of it up.

Gdeaver 07-04-2008 00:47

Re: 2009 Control System Possibility?
 
What's ahead for 2009? Look what First has shown so far. LEGO league is NXT. FTC will be a NXT with an add on board for motors and sensor expansion. Note that the LEGO NXT base includes closed loop motor control. While it allows for raw a to d sensors, the sensor ports clearly show the intention to use full conditioned and inteligent sensors that comunicate thier state by I2C master slave bus comunication. The currently un used but enormously powerful feature of the NXT is the high speed RS485 master slave multi drop port.
This is a totaly different hardware platform from what IFI has provided the FIRST comunity. I would bet some money ( maybe 5 cents) that the new 2009 FRC would also be a more capable version of this hardware platform. So FTC will have a ST MIcro ARM7 as the master (where we write the main robot controll program), a ATMEL microcontroller slave to do A to D, a BLUE TOOTH comunications slave, a graphic LCD slave ( state or diagnostic display), 3 I2C ports for inteligent motor and sensors, and a high speed port for the realy heavy duty needs. The platform is expandable. I wondered which direction FIRST would go back in this thread.
http://www.chiefdelphi.com/forums/sh...679#post641679
If FIRST does go down this path, what about software? Looking at the new FTC system there is the NXTG graphical drag and drop NI developed platform, the NI student version of Labview with NXT plug in blocks, CM Robot C , maybe Easy C, open source? and hate to bring it up but MSRS. That's allot of programming options.This is a very different environment than the IFI system. Any body that thinks this platform is going to be too easy and not expose students to serious programming probably never worked with distributed serialized control systems before. This platform could allow us to abstract at a high level and also have the need to show students the low level down and dirty progamming. The high level is done on the ARM master and the low level is on the microcontroler on the inteligent sensors and motor controllers.
It's hard enough to develop a state machine to control something like a robot. The thought of programing it at the low level in MPLAB makes my eyes glaze over. If NI does it right we could be writing state machines in lab view next year. If This is the new FRC platform, I hope the game committe takes pitty on us next year and gives us an easy game. Change is nasty but it happens.

Qbranch 07-04-2008 08:07

Re: 2009 Control System Possibility?
 
I feel bad IFI is getting the boot from FIRST... i kinda hope it doesn't happen, at least for the field control and such... plus, it won't be as easy as saying "Hey, where's the IFI guy?" anymore when you have a radio problem or whatever... saying "Hey, where's the FIRST guy?" won't really get you very far. :o

I'm guessing it's a price thing... the FRC controller is mighty expensive.

But, if FIRST is really designing their own controller, a few specs i'd like to see:

> tiDSP processor (or, if they want to stay with microchip, a PIC32 would be nice too)
> digital serial communication (of some sort) to motor controllers w/higher chop frequency (to get rid of the angry buzzing associated with most first robots)
> same 16 channel analog in
> i'm ok with the number of digital I/O pins, but it'd be nice to have a few more (maybe like a total of 24 instead of 18)
> some sort of locking mechanism to hold the pwm cables on or a mass pwm connector so all your cables can be connected to a main terminal block, say, one for all your analog inputs, then that whole block can be locked into the control board.
> gyro and accelerometer chips mounted on the main controller PC board near processor anaog pins to minimize possibility of electrical interference.
> 5v tolerant I/O (may require level converters for I/O)
> ZigBee radio
> Programming port on OI panel along with program mode button on OI panel.

And... yeah that'd be good. :]

-q

whytheheckme 07-04-2008 08:39

Re: 2009 Control System Possibility?
 
Quote:

Originally Posted by Qbranch (Post 731923)
> some sort of locking mechanism to hold the pwm cables on or a mass pwm connector so all your cables can be connected to a main terminal block, say, one for all your analog inputs, then that whole block can be locked into the control board.

*sigh* - Back to the good old days.

Yes, those are DB-25 Cup connectors for the analog and digital I/O.

tee-hee-hee
Jacob

Adam Y. 07-04-2008 09:50

Re: 2009 Control System Possibility?
 
Quote:

Originally Posted by Qbranch (Post 731923)

That's never going to happen unless you want the controller to be more expensive than it is right now. Those DSPs makes working with the current controllers in the lowest level possible like a game of patty cake. Even engineering a control board would make the current design look simple by comparison. They may be powerful but they have some really funky design requirments and at those speeds you start dealing with the laws of physics that are a pain to correctly deal with. Also, the documentation was the size of a textbook. Why would you need a Digital Signal Processor? A lot of the capabilities would be wasted because of the fact that the device is designed specifically for doing signal processing.
Quote:

Someone also made the argument (I'll have to paraphrase) that in the non-FIRST world "mechanical stuff just works, and it's all about the software". My experiences in the various disciplines over the years don't support that. The opposite, actually. Software doesn't wear out. The first copy of the executable file is identical to the 400,000th copy of the executable file. Software doesn't need to be crash tested (physically, at least), vibration tested, EMC tested, UL tested, etc.
Actually that is wrong and is much more complcated than you put it. You need to know how the mechanics work before you can program the electronics. If you don't as one Texas Instruments engineer put it you would design a system that mathematically could explode the world. I don't think anyone actually does that in FIRST but that is how you are supposed to do the design work in real life. Of course this falls into the realm of electrical engineering and not programing.

neutrino15 07-04-2008 13:43

Re: 2009 Control System Possibility?
 
Code:

if(BLUETOOTH == true && NATIVE_FLOAT == true){
    printf("epoch win");
} else {
    printf("mehh");
}


Greg Marra 07-04-2008 15:16

Re: 2009 Control System Possibility?
 
Quote:

Originally Posted by neutrino15 (Post 732095)
Code:

if(BLUETOOTH == true && NATIVE_FLOAT == true){
    printf("epoch win");
} else {
    printf("mehh");
}


What issues do people run into doing in integer math instead of floating point? The only thing I can think of are trigonometric functions, but a simple lookup table makes that a non-issue. What would be easier with floating point?

Qbranch 07-04-2008 18:34

Re: 2009 Control System Possibility?
 
Quote:

Originally Posted by Adam Y. (Post 731973)
That's never going to happen unless you want the controller to be more expensive than it is right now. Those DSPs makes working with the current controllers in the lowest level possible like a game of patty cake. Even engineering a control board would make the current design look simple by comparison. They may be powerful but they have some really funky design requirments and at those speeds you start dealing with the laws of physics that are a pain to correctly deal with. Also, the documentation was the size of a textbook. Why would you need a Digital Signal Processor? A lot of the capabilities would be wasted because of the fact that the device is designed specifically for doing signal processing.

I'll give you the expensive part, at list price. However, having a processor like this would open up some interesting possibilities... if you set up the DMA with the analog converter, and use a special event trigger on a Compare match, you can get yourself a mostly hardware method of getting images from a camera. It'd be awesome to empower teams to use pre-canned image processing algorithms or tweak/perfect their own since everything would be done on the same processor.

I realize they have extreme rates of change on their digital lines (0->VDD VDD->0 transitions) that can ring far up in the high frequency electromagnetic spectrum. It could be a problem, but there are PCB design softwares available from multiple manufacturers today (Like Mentor Graphics) that incorporate high frequency physics tools into their auto routers and simulation environments. I don't think it's beyond the capacity of FIRST to pull off.

For what most teams do, yes, it's overkill... but as a note some universities use these ti processors in controls classes because they have enough speed to both do vision processing and silky smooth motion control at the same time to make neat robots that can do things like balance like a segway and follow a colored ball at the same time, from the same processor.

But anyways, if you don't want to make the jump to light speed, but still make a jump to slipspace, Microchip is coming out with a line of 32 bit cores that run at 80MIPS as opposed to the current 8-bit processor's 40, and i imagine these processors i mentioned in my previous post will be much more affordable than the tiDSP, while still enableing some pretty fancy footwork motion control capabilities (the whole single-instruction-fractional divide, single-instruction square and accumulate :yikes: , and vectored interrupts in the new PIC32's makes me sweat cold :o ) I'm really looking forward to their release date.

Does that mean I'm geeky? :]

-q

EricVanWyk 07-04-2008 18:42

Re: 2009 Control System Possibility?
 
Quote:

Originally Posted by Adam Y. (Post 731973)
That's never going to happen unless you want the controller to be more expensive than it is right now. Those DSPs makes working with the current controllers in the lowest level possible like a game of patty cake. Even engineering a control board would make the current design look simple by comparison. They may be powerful but they have some really funky design requirments and at those speeds you start dealing with the laws of physics that are a pain to correctly deal with. Also, the documentation was the size of a textbook. Why would you need a Digital Signal Processor? A lot of the capabilities would be wasted because of the fact that the device is designed specifically for doing signal processing.

Couldn't disagree with you more. Any electrical engineer worth her salt can whip up a tiDSP board in without much hassle. A C2000 DSC from TI is no harder nor easier to include in a design than a PIC is. Granted, there are some large pin count BGA options in that family, but that is just process control.

Also, note that they are "Digital Signal Controllers", rather than "Digital Signal Processors". The difference is perhaps semantics, but the C2000s feel a lot like a microcontroller with a gorgeous math processor. Imagine for a moment what types of control loops you could run on them.

Lastly - accounting for physics is really really easy at their speeds. They run as fast as 150MHz _internal_. 150MHz is pretty tame, all things considered.

thefro526 07-04-2008 18:55

Re: 2009 Control System Possibility?
 
Quote:

Originally Posted by Qbranch (Post 732278)

Does that mean I'm geeky? :]

-q

Q, I've officially decided that should the choice be mine, I would have you design the new control system. Everything you've said has gone far over my head, but after seeing your teams bot this year I'm confident that you could design something that would be a standard for the future.

Qbranch 07-04-2008 19:13

Re: 2009 Control System Possibility?
 
Quote:

Originally Posted by thefro526 (Post 732290)
Q, I've officially decided that should the choice be mine, I would have you design the new control system. Everything you've said has gone far over my head, but after seeing your teams bot this year I'm confident that you could design something that would be a standard for the future.

Well, uhm, gee thanks for the compliment! However, I suggest you come back to me in a couple years after i've been at UIUC for Electrical Engineering for a while before you ask me to design a control board with enough cool hardware and a low enough price to make me grin at it. :o

Also, I've heard rumors that FIRST has been collecting engineers in preparation for taking on the engineering load of designing and maintaining their own control system hardware/software. (source: a mentor on our team watches whenever FIRST opens up job positions and has seen a lot of engineer hiring lately)

Come by and see us sometime in Atlanta!

-q

adman 07-04-2008 19:43

Re: 2009 Control System Possibility?
 
Quote:

Originally Posted by EricVanWyk (Post 732280)
Couldn't disagree with you more. Any electrical engineer worth her salt can whip up a tiDSP board in without much hassle. A C2000 DSC from TI is no harder nor easier to include in a design than a PIC is. Granted, there are some large pin count BGA options in that family, but that is just process control.

Also, note that they are "Digital Signal Controllers", rather than "Digital Signal Processors". The difference is perhaps semantics, but the C2000s feel a lot like a microcontroller with a gorgeous math processor. Imagine for a moment what types of control loops you could run on them.

Lastly - accounting for physics is really really easy at their speeds. They run as fast as 150MHz _internal_. 150MHz is pretty tame, all things considered.

Quite right on the Comments. Remember these new hot rod DSP or DSC chips
come with a C programming level abstraction. You don't have to know
what the hardware is as long as all your friendly code comes along for
the ride ( knowing pin outs is still a must:ahh: ) but programming is the
same as always pretty much except it is pretty much light speed. Microchip's
24 and 32 series has a really great auto data collector called Direct Memory
Access or DMA. It means the core processor doesn't even see the data
going by from the A/D or CAN or Communications Ports.

This lets your real code be really busy without messing with a bunch of
interrupts until you say so and want to look over all that data its collected
for you.

I hope we don't go Graphical Programming. If you look real hard you will notice that LABVIEW has "script type boxes" to put real code in when
LABVIEW starts to choke. The one caveat here is though if they go to
some sort of multi-core processor Labview can run multiple threads (programs) at the same time. No interleaving or round robin(sharing).
That starts the beginning of ARTIFICIAL INTELLIGENCE ALGORITHMS!:eek:
Now your robot can make some decisions on its own like full collision
avoidance based on a camera. Not at all of the realm of multicore.

Who knows. Maybe it won't work and they will go back to IFI?

petek 07-04-2008 21:21

Re: 2009 Control System Possibility?
 
Quote:

Originally Posted by Qbranch (Post 732302)
Also, I've heard rumors that FIRST has been collecting engineers in preparation for taking on the engineering load of designing and maintaining their own control system hardware/software. (source: a mentor on our team watches whenever FIRST opens up job positions and has seen a lot of engineer hiring lately/
-q

You mean like this? Looks more like evaluating outsourced components than development to me.

Adam Y. 08-04-2008 10:10

Re: 2009 Control System Possibility?
 
Quote:

Originally Posted by EricVanWyk (Post 732280)
Couldn't disagree with you more. Any electrical engineer worth her salt can whip up a tiDSP board in without much hassle. A C2000 DSC from TI is no harder nor easier to include in a design than a PIC is. Granted, there are some large pin count BGA options in that family, but that is just process control.

No. It's definatly harder. Those chips turn a lot of fairly trivial issues for a PIC into a giant big hullabaloo. I understand why. The specifications of that series of chips are amazing but creates a whole host of problems which you won't see with a PIC.

Tom Bottiglieri 08-04-2008 10:14

Re: 2009 Control System Possibility?
 
Data flows are pretty cool.
Data flows inside of state machines are even cooler, and really powerful.

Danny Diaz 08-04-2008 15:00

Re: 2009 Control System Possibility?
 
Quote:

Originally Posted by adman (Post 732324)
I hope we don't go Graphical Programming. If you look real hard you will notice that LABVIEW has "script type boxes" to put real code in when LABVIEW starts to choke. The one caveat here is though if they go to
some sort of multi-core processor Labview can run multiple threads (programs) at the same time. No interleaving or round robin(sharing).

Ahahaha. Those "script type boxes" are for multiple reasons, but definitely not for "when LabVIEW starts to choke." There are multiple "scripting" mechanisms in LabVIEW, the one most people are familiar with is "MathScript" and it's for those who are familiar with using similar scripting in other industry packages, such as MatLab. I do agree, Multicore programming is made easy with LabVIEW, and it has enabled engineers to make use of multicore hardware in new ways.

-Danny

Chris_Elston 21-04-2008 08:13

Re: 2009 Control System Possibility?
 
Quote:

Originally Posted by Travis Hoffman (Post 723696)
Well heck, why don't we slap an Allen-Bradley PLC on each robot and call it a day? :P

I am 100% onboard with that! Compact Logix controller would be sweet.

Ladder logic would be easy to program the robots.

Racer26 25-04-2008 09:05

Re: 2009 Control System Possibility?
 
Well, I guess all our questions have been answered, and this is no longer a question.

My speculation about 802.11 WAS correct, just I was off-base on the IFI portion of it, it's an NI CompactRIO.


All times are GMT -5. The time now is 03:22.

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