Jaguars vs Victors

[Joe Johnson]

Originally Posted by Al Skierkiewicz

Joe,
We really need to get together and talk. Are you up for a challenge? I have an assignment you might be interested in.
Al

Right now I am getting my team ready for BU in 22 days, but after that, yeah, maybe.

As to those who say teams have invested bucks in all the crazy quilt hardware that is required to make the current system function, FIRST can always grandfather that hot mess in for a few years. But seriously, this current system is far from free. It cost a lot of money (and labor not to mention blood, sweat, and tears) to wire up all these distributed devices.

And for what? Not much in my humble opinion.

Think about it. If FIRST wants to keep the router on the robot morphology, then this box could be ethernet device. Just like the Jaguars, they could force the device to prove it is running an approved version of firmware and then have that firmware shut everything off if an enable message that only FIRST approved software can generate (although rumor has it that folks have broken the Jaguar protocol -- in theory a reasonably secure system could be designed, we are not running military hardware here -- there is not a lot of benefit to someone being able to spoof the enable/disable signal on a FIRST robot).

Once you have that box on board your robot, you can have basically any controller you want on your robot. Put a Pandaboard on board, or a PC or a CRIO or an IFI system. Do whatever you want. All the IO that matters is controlled by FIRST.

This is SO doable.

Joe J.

[techhelpbb]

Originally Posted by Joe Johnson

And for what? Not much in my humble opinion.

Things I think a student can learn from this system as it is designed:

1. How to wire robotics systems.
2. How to deal with modular systems (like those often found in automobiles, HVAC, industrial application) and their complexities.
3. Electronics (and frankly given I was a vocational technical student for electronics in high school I know this is very good thing to learn at the relevant age bracket). (I feel that this is a challenge that is not being well served however...the pathway to provide electronics education from this is not well defined.)

I am concerned about the idea of reducing the entire project to the sort of thing we find in the other age brackets with Lego NXT and Vex controllers. Not that these aren't admirable for handing you a system (and the limits of that system) in a simple box but because teams actually do manage to make this work. What I feel we as a group need to do is stop 'bleeding' and start working smarter. We need a process to vet vendors and fill the holes where they exist.

[techhelpbb]

Originally Posted by Joe Johnson

Think about it. If FIRST wants to keep the router on the robot morphology, then this box could be ethernet device. Just like the Jaguars, they could force the device to prove it is running an approved version of firmware and then have that firmware shut everything off if an enable message that only FIRST approved software can generate (although rumor has it that folks have broken the Jaguar protocol -- in theory a reasonably secure system could be designed, we are not running military hardware here -- there is not a lot of benefit to someone being able to spoof the enable/disable signal on a FIRST robot).

Once you have that box on board your robot, you can have basically any controller you want on your robot. Put a Pandaboard on board, or a PC or a CRIO or an IFI system. Do whatever you want. All the IO that matters is controlled by FIRST.

This is SO doable.

Joe J.

Yeap, in effect I already have this.

I have a robot controller made from Parallax Propellers (several).
The Propeller produces a virtual serial port over the USB connection typical on the development board.
I have that connected to a dual band NetGear N WiFi router running a patched version of DD-WRT.
This NetGear box has a USB port for sharing printers, I snagged it to plug in the Propeller (handy that).

Therefore the WiFi box in this case is hardware provided by NetGear and software mostly provided by the DD-WRT community.

I chose the Parallax Propeller because of the 8 cogs and the many shared I/O lines. With this you don't need to task switch you can run 8 process with one in each cog at 20Mips (if you don't overclock). With a few of them (and they are cheap) you get dozens and dozens of I/O.

Reading encoders is not a problem when you have 20Mips to do whatever you feel like with (in BASIC, assembler or C).
I can send code to it...and it doesn't take like 5 minutes to do either!

I get around the power issue the same way the cRIO basically does. The battery is pulled through a step-up regulator from whatever the battery voltage is to 24VDC (sort of like the cRIO) and then 3 step-down regulators provide 3.3VDC (for the Propellers), 5VDC for various I/O and 12VDC for relay coils (yes I have electromechanical relays on this...and they work dandy). The battery can cave well below 3VDC and this will not even blink. It's easy to get to 5V I/O using either level converters or 2N7000 MOSFETs.

Currently this frame is equipped with Jaguars and one speed control I built myself (my speed control does CAN as well thanks to some handy parts from Microchip).

[techhelpbb]

Originally Posted by Joe Johnson

Once you have that box on board your robot, you can have basically any controller you want on your robot. Put a Pandaboard on board, or a PC or a CRIO or an IFI system. Do whatever you want. All the IO that matters is controlled by FIRST.

This is SO doable.

Joe J.

Now that I've explained what I've already built since last year, I'd like to point out that this may not be an arms race that is wise to start.

There are countless high performance items that could end up on robots. Parallex Propellers, GreenArray GA144s, Altera and Xilinx FPGA and that's not counting the likely laptops and embedded PCs that'll show up.

And yes...this probably would get crazy:
http://www.objectivej.com/hardware/p...ter/index.html
(Pull the red wire...the red wire!)

Someone's bound to show up with a laptop on the robot this year.

[Matt Krass]

Originally Posted by techhelpbb

There are countless high performance items that could end up on robots. Parallex Propellers, GreenArray GA144s, Altera and Xilinx FPGA and that's not counting the likely laptops and embedded PCs that'll show up.

And yes...this probably would get crazy:
http://www.objectivej.com/hardware/p...ter/index.html
(Pull the red wire...the red wire!)

Now this said, someone's bound to show up with a laptop on the robot this year.

There's really not much preventing that this year, there is a variety of ways to mount an embedded PC on the robot and have it use the cRio as a pretty pricey, FIRST controlled I/O expander, using an Ethernet link or something similar. In which case it behaves like the system you and Joe described.

Personally, I'd really like to see FIRST open up the control system with a design competition. Let teams design and submit control system ideas, designed around what teams want/need and their resources and let the FIRST community and it's thousands of brilliant minds weigh in. We already have a competition to design robots in the winter and spring, why not control system summer and fall?

While the guys at NI and TI have done an admirable job, I do agree the current system is an amalgam of several good ideas with bits hacked together to work in a manner that's.... well let's go with frustrating. But those guys were small in numbers, and probably did not have all that much to work with. I sincerely think the mentors and students of FIRST stand a good chance of coming up with an effective, workable solution to our somewhat oddball use case. Even if only because of the sheer amounts of brainpower we have at our disposal.

But this isn't the thread for that idea. I'm not sure that thread exists (yet).

Back on-topic:
It'd be really interesting to see a qualitative side-by-side test of a new Jag vs a new Victor with both buried in temperature sensors and voltage and current probes. Perhaps even some rig with an active matching network between a Jag and a Victor running in complement. Say the Jag running 'forward' supplying a steady current in the 30A range, and the Victor running 'reverse' sinking the same current, with some kind of active FET arrangement to regulate current flow between the two. This would ensure that they're both being exposed to very close to if not the exact same conditions across all tests. You could do these tests at a variety of power levels and compare.

Eric, Joe, Al, what do you guys think of that idea?

[Al Skierkiewicz]

Matt,
I like the idea of a competition. I would like to assemble a list of what such a system must have prior to any competition. I am an official old guy and I try to help rookies whenever and wherever I can. In the past we had some pretty easy to use hardware that an inexperienced mentor and students could take out of the box, look at a simple block wiring diagram, start adding wires and have a robot driving in an hour or two. Granted, it didn't have the computing power some of the new software geeks wanted and it had some other limitations that were solved by the manufacturers. However, it had a few good qualities as well. It was small, lightweight, easy to use, easy to control and had sufficient tally lights to tell you what was happening.
So here is my list...
1. Out of the box it has to work for rookies running default software or at least is easily loaded with default software without any other programming in less than one half hour.
2. Can control Jags or Victors, Spikes or whatever control devices someone wants to include to drive motors and such.
3. Can run down to 4 volts input.
4. Has imbedded wireless controls of some sort.
5. Has sufficient software power to process sensors, cameras, etc. and development includes C++, Java, Labview or any other development software in general use.
6. Has at least a serial port and an ethernet port, several would be ideal.
7. Has sufficient I/O for at least 8 or 16 PWM, relay, solenoid, digital and analog ports and/or can be simply expanded for the I/O needed (i.e. plugin modules).
8. I/O is easily accomplished without sophisticated tooling.
9. Is a mature product or product line available to all teams, domestic and foreign.
10. Always of interest is something that is low cost, or is manufactured by a company interested in donating sufficient quantities to help our teams keep costs low.

Please keep in mind that team expansion is increasing by leaps and bounds and could easily reach 8-10,000 in this decade. Please feel free to add to this list your requirements.
I would be remiss if I failed to thank our current suppliers for their continued support to this organization, especially NI, IFI, TI and all the other suppliers who make this competition fun for our students and challenging for our mentors.

[Matt Krass]

Originally Posted by Al Skierkiewicz

Matt,
I like the idea of a competition. I would like to assemble a list of what such a system must have prior to any competition. I am an official old guy and I try to help rookies whenever and wherever I can. In the past we had some pretty easy to use hardware that an inexperienced mentor and students could take out of the box, look at a simple block wiring diagram, start adding wires and have a robot driving in an hour or two. Granted, it didn't have the computing power some of the new software geeks wanted and it had some other limitations that were solved by the manufacturers. However, it had a few good qualities as well. It was small, lightweight, easy to use, easy to control and had sufficient tally lights to tell you what was happening.

According to our students, I'm also an official old guy (I don't get it) but I think I have a few good years left I have had extensive experience with the IFI controllers and the current cRio controllers and I wholeheartedly agree. The new system is vastly over-complicated for our use case. As far as the new computing power... Eh. In terms of raw power, yes it's more capable, but we burn up a good ton of that with CAN, TCP/IP, the VxWorks RTOS, etc. At the end of the day, I don't think it really works out to be much of a difference. I feel we have the same challenge in getting the thing working with sensors and vision tracking that we had in 2006, only now everything is more expensive, and requires more configuration. And because we're so far from the bare metal, I feel a lot of the impact is lost. Students no longer have to understand why a pot or encoder works, just how to type "Encoder" in to their programming language and have magic numbers show up. What kind of problem solving do you learn from being handed premade solutions?

(Yes, FIRST is not about teaching engineering it's about Inspiration, but what is so inspiring about learning to expect someone to do your job for you?)

Originally Posted by Al Skierkiewicz

So here is my list...
1. Out of the box it has to work for rookies running default software or at least is easily loaded with default software without any other programming in less than one half hour.
2. Can control Jags or Victors, Spikes or whatever control devices someone wants to include to drive motors and such.
3. Can run down to 4 volts input.
4. Has imbedded wireless controls of some sort.
5. Has sufficient software power to process sensors, cameras, etc. and development includes C++, Java, Labview or any other development software in general use.
6. Has at least a serial port and an ethernet port, several would be ideal.
7. Has sufficient I/O for at least 8 or 16 PWM, relay, solenoid, digital and analog ports and/or can be simply expanded for the I/O needed (i.e. plugin modules).
8. I/O is easily accomplished without sophisticated tooling.
9. Is a mature product or product line available to all teams, domestic and foreign.
10. Always of interest is something that is low cost, or is manufactured by a company interested in donating sufficient quantities to help our teams keep costs low.

Please keep in mind that team expansion is increasing by leaps and bounds and could easily reach 8-10,000 in this decade. Please feel free to add to this list your requirements.

I think the architecture of the IFI system is pretty close to this. It was much more self contained. I think a similar structure with more horsepower (but not so much more that we need all the support systems the cRio has) and a simpler development environment would be ideal. Especially if we did away with the silly licensing issues we always seem to have every January.

On top of that, a big requirement from me is that it be more robust, and i don't mean in terms of environmental conditions. I mean high school students plugging it in backwards and short circuiting it and getting swarf (still laughing) in it. I think the blue bits are quite well designed, based on the fact that my students haven't managed to kill them yet .

Originally Posted by Al Skierkiewicz

I would be remiss if I failed to thank our current suppliers for their continued support to this organization, especially NI, IFI, TI and all the other suppliers who make this competition fun for our students and challenging for our mentors.

While I am somewhat critical of the system we have now, I'd like to make it clear I don't think it's a failure or oversight of anyone working on the system. Engineering constraints are a bear, and I think everyone involved has done a great job, I just think they may have been starting at a serious disadvantage with the wrong platform for the job. So I also thank the suppliers and engineers for their help.

Matt

[techhelpbb]

Originally Posted by Matt Krass

I think the architecture of the IFI system is pretty close to this. It was much more self contained. I think a similar structure with more horsepower (but not so much more that we need all the support systems the cRio has) and a simpler development environment would be ideal. Especially if we did away with the silly licensing issues we always seem to have every January.

While I am somewhat critical of the system we have now, I'd like to make it clear I don't think it's a failure or oversight of anyone working on the system. Engineering constraints are a bear, and I think everyone involved has done a great job, I just think they may have been starting at a serious disadvantage with the wrong platform for the job. So I also thank the suppliers and engineers for their help.

Matt

The one shortcoming of the IFI system I've seen recently was the documentation for the cables to connect them to the radios.

Surely that would not seem to me to be a design issue, but rather a process issue in that once it was designed and it worked the information should have been distributed.

This only became more critical after FIRST shifted to the cRIO because teams like ours have a rather sizable pile of these and of course the cables have been lost.

I was able to figure this out because I fix electronics all the time, but a search for this pinout didn't seem to produce results. I certainly don't blame anyone for that sort of thing. It's just one of those things that after you figure it out, you really should have a place to distribute that information.

(Unless someone has this information somewhere, I'm willing to provide what I discovered provided it doesn't violate IFI's intellectual property and anyone wants it.)

I to would like to clarify that I have nothing against the work of the vendors involved. I work with them beyond FIRST all the time, I just would like to find a pathway to clear communications and a good fitting solution.

[Dave Flowerday]

Originally Posted by Al Skierkiewicz

So here is my list...
1. Out of the box it has to work for rookies running default software or at least is easily loaded with default software without any other programming in less than one half hour.
2. Can control Jags or Victors, Spikes or whatever control devices someone wants to include to drive motors and such.
3. Can run down to 4 volts input.
4. Has imbedded wireless controls of some sort.
5. Has sufficient software power to process sensors, cameras, etc. and development includes C++, Java, Labview or any other development software in general use.
6. Has at least a serial port and an ethernet port, several would be ideal.
7. Has sufficient I/O for at least 8 or 16 PWM, relay, solenoid, digital and analog ports and/or can be simply expanded for the I/O needed (i.e. plugin modules).
8. I/O is easily accomplished without sophisticated tooling.
9. Is a mature product or product line available to all teams, domestic and foreign.
10. Always of interest is something that is low cost, or is manufactured by a company interested in donating sufficient quantities to help our teams keep costs low.

*cough*
http://www.vexrobotics.com/products/.../217-2180.html
*cough*

It has everything on your list except CAN and Ethernet. However, it DOES have a USB host port (which should also be on your list), so adding Ethernet is trivial (or better yet, use USB devices like cameras instead of Ethernet - they're cheaper). I'm sure there's some USB->CAN device out there, or someone could make one. Best of all, it's made by a manufacturer with a proven track record.

Solutions to this issue clearly exist (or are at least a lot closer than what FIRST has now). I don't think this is a technological problem, however.

[techhelpbb]

Originally Posted by Dave Flowerday

It has everything on your list except CAN and Ethernet. However, it DOES have a USB host port (which should also be on your list), so adding Ethernet is trivial (or better yet, use USB devices like cameras instead of Ethernet - they're cheaper).

Firstly I like this product and what it was based off of, so this is not intended to downplay what it is.

I don't know if for the purposes of FRC you're not just better off buying a cheap general x86 embedded board or laptop to put on the robot for that price. It would serve a lot of purposes, offer Ethernet, WiFi, and even most cheap netbooks have 2 USB root hubs for at least 2 webcams. A cheap multi-tt capable hub might allow more. The hard drives can easily be replaced (or come as is) with solid state drives, or you can always use flash USB drives, compact flash or camera memory in a suitable reader with BIOS boot support (or some combination with an appropriate boot loader).

Plus if you use something like the driver's station you might be able to work a bulk discount.

Additionally, when the control system is no longer the current model, this leaves you with...a PC.

Obviously this VEX product offers the integration with PWM, digital to analog conversion, and other aspects, but it's not hard to add most of that to an x86 computer, or even supplement the computer with a powerful microcontroller or FPGA via USB, USB-CAN, USB-RS232, USB-422/485 or ethernet.

This is very broad and while I love this communication, I wonder if we've manage to hijack this topic. Perhaps we can start a new topic and link it?

The last I read in this topic the idea was to produce measurements to compare the Jaguar and the Victors and the interest in that effort.

[Al Skierkiewicz]

Guys,
Before we start making recommendations I would still like to get a list of must haves and would like to haves if possible. I like the USB ports idea.

[Matt Krass]

Originally Posted by techhelpbb

The last I read in this topic the idea was to produce measurements to compare the Jaguar and the Victors and the interest in that effort.

I'm a fan of this idea, I didn't mean to accidentally kick off a whole new topic in here to that end I've started a new thread here to continue this discussion.

Back on to Victors and Jaguars, I'd really like the opinion of some of the veteran EEs around here on my idea for a test rig I mentioned earlier. Essentially, I'd be alternating between a Jaguar sourcing current to a Victor and the opposite, using something with a sufficiently intelligent brain to control both and perhaps some kind of active load between them. While doing this, we can monitor all of their vitals (mostly temperature of the FETs in question) and we can do some pretty terrible things to them and see how they handle it.

A bank of FETs with beefy heat sinks combined with some smoothing LC networks off each speed controller would make a nice load I think, how about it?

Matt

[techhelpbb]

Originally Posted by Al Skierkiewicz

Guys,
Before we start making recommendations I would still like to get a list of must haves and would like to haves if possible. I like the USB ports idea.

One issue with USB is the cabling. It's fine for webcams and the like, but a lot of peripherals have molded connectors and that's not always easy to work with if you have to snake framework in your robot (sure you can cut off the connectors but that can cause issues). However, a controller that has USB host capability in plural opens the door to a lot of cool cheap COTS hardware (http://www.thinkgeek.com/geektoys/warfare/8a0f/ stuff like that.).

Lower part of this moved to new topic...http://www.chiefdelphi.com/forums/sh...d.php?t=104114
Thanks

[techhelpbb]

Moved to new topic...http://www.chiefdelphi.com/forums/sh...d.php?t=104114
Thanks.

[Matt Krass]

EDIT: I'm removing the comments here in the interest of thread purity, I've reposted them in the new thread I made for control system design thoughts, linked below

I'm loving these suggestions, but as you pointed out, we're really derailing this thread, so I'm going to ask that you guys divert to the thread I made for this here.

Thanks,
Matt