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.

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

Re: 2009 Control System Possibility?
 

*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

Re: 2009 Control System Possibility?
 

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.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.

Re: 2009 Control System Possibility?
 

Re: 2009 Control System Possibility?
 

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?

Re: 2009 Control System Possibility?
 

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

Re: 2009 Control System Possibility?
 

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.

Re: 2009 Control System Possibility?
 

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.

Re: 2009 Control System Possibility?
 

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

Re: 2009 Control System Possibility?
 

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?

Re: 2009 Control System Possibility?
 

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

Re: 2009 Control System Possibility?
 

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.

Re: 2009 Control System Possibility?
 

Data flows are pretty cool.
Data flows inside of state machines are even cooler, and really powerful.

Re: 2009 Control System Possibility?
 

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