Re: Control System Design Contest Proposal
 

What concerns me is that during several matches last year we had a situation where the robot clearly lost communications. Completely several times over several matches. During those times the field was actually behaving irradically, music timed wrong, events happening off queue (this was not a major competition thank goodness more a local expo).

We tried to use the DS (driver's station) information but it wasn't clear that it was representative that all messages sent were effectively received properly. What I'm looking for is a way to be sure from both the robot and the driver's station that everything we are communicating is getting to where it should. Packet statistics and packet CRCs might help (UDP is obviously gonna need some form of tracking more than TCP which is reliable). I just am not confident of how all this information with what we already have confirms that everything sent to the robot is getting to the cRIO. Is there some documentation I can refer to on this?

We have experimented with logging back to the DS from the robot but we found that the additional traffic and the additional programming had several undesirable results. I'm sure that has application, but for some problems keeping the path to be written to a log short and as simple as possible is desirable. We looked earlier to see if we can access robot flash from Java. Can you point us in the direction of how we can learn more about that?

Thanks.

Re: Control System Design Contest Proposal
 

The Charts tab is new this year and was implemented to help shed light on situations like you describe without adding overhead to the robot code. All critical field communication is via UDP with CRCs. Video uses TCP/HTTP. With more insight into what this logging doesn't capture, it is feasible that the default code or FRC_Communications may start logging additional data.

As a CSA, I've seen many robots that didn't move or stopped moving, and the field is the easiest element to point to, but in my experience, it is rarely the issue -- exceptions are damaged field cables and connectors and some late night debug sessions where zero robots could connect that required a reset of the access point. Hopefully the charts tab, especially if the code is instrumented, will help hilight the SW, radio, electrical, and other issues for quicker debugging and resolution. And in those rare situations when the field or field radio are to blame, I hope the charts tab on the various robots helps that debugging as well.

If anyone has a mysterious match that didn't go well, I'll be happy to review the log/tea leaves and see if we can shed some light. The log file viewer is in the Program Files/FRC Driver Station folder, and the logs are in the Public Users/Documents/FRC/Logs folder.

To log to flash from any of the languages, you should be able to use the file I/O APIs. I know this work on C++ and LV, and I'm pretty sure it works on Java, but I can't verify it.

Greg McKaskle

Re: Control System Design Contest Proposal
 

I'd propose the TI Beagle Bone and this Wifi device rovingnetworks.com RN_121.

The TI Beagle Bone boots in under three seconds. It is a full Linux system inside. The thing I like is the Node.js using the Cloud9 IDE. But you could program in the language of your choice. $90.

The RN 121 is a WiFi device that has digital inputs and outputs, analog inputs and a UART for data streams. $40

The Bone isn't going to do onboard video processing, on the other hand there are lots of better add in hardware that would be able to do that. Nice thing about the Bone someone smart could put a image processor on a "cape".

If you want a few more CPU cycles then the Beagle Board is a better choice at about $180

Re: Control System Design Contest Proposal
 

I was just reading about the BeagleBone yesterday, and I thought I saw boot time of closer to one minute. I googled and found a pared down custom kernel boot time of 15 seconds. Do you have a source for the three second boot?

Since I work for NI, anything I say/ask can easily come off as defensive, but please don't take it that way. As I said, I'm playing with one too, or at least I hope to this afternoon, and thus far it seems very cool. Without a cape, it seems like the I/O is pretty limited, and I'm a little concerned about burning it up if I short pins or reverse a cable, but it is a cool and capable little board.

In San Antonio, I spoke with 118, who are using one for image processing for this year's game, so I don't really understand you comments in that regard. Any experience to the contrary?

Greg McKaskle

Re: Control System Design Contest Proposal
 

Guys,
When I started this question I was really intending that we start with a list of things we would want to see in the future. We should keep discussion to a minimum for the time being, please and just focus on the list. We can have discussions in another thread but between the two threads already talking on this subject, we will not be able to get a comprehensive list.
Thanks.
Al

Re: Control System Design Contest Proposal
 

Sorry about that. How about rephrasing it as a requirement?

The system communications should be sufficiently transparent, or have sufficient diagnostics, so that teams are able to get their robot moving ...
in their shop or classroom,
in the pits,
on the practice field,
on the official field,
without resorting to 50 foot tethers.

And when it doesn't move, they are able to effectively debug the issue instead of blaming field gremlins.

Greg McKaskle

Re: Control System Design Contest Proposal
 

Following up the direction this topic spawned from...

Our team successfully deployed a netbook laptop with the screen removed, the original battery, and an SSD at a competition on our robot. It was connected to more than one USB webcam. Further, we did drive right over the bump in the field repeatedly with the laptop inside the robot.

I post this as a community service as this issue has been danced around before. The only concern we encountered was the cost restriction applicable to the item under the rules. We were able to satisfy the officials in that regard.

The laptop did not replace the cRIO, but was connected to the Ethernet segment on the robot.

In short, you can legally put a laptop on your robot (within the applicable restrictions) with the laptop's original battery, but you can't replace the cRIO or the related power controlling functions with it. You can, however, instruct the cRIO to do things with those power controlling functions from the laptop.

Have fun...and let's see how long it is before someone starts using NVidia's CUDA technology for something.

Re: Control System Design Contest Proposal
 

I'll admit, I haven't read this entire thread, but it looks very interesting, and I intend to read it in full later. On the note of radio boot time, my understanding is the 2009 radios booted right up, but they went out of production and we now have the DAP-1522s, which may or may not be changed at some time in the future to something that boots faster (for the record, the DAPs take about 50 seconds).

Also, I was thinking about this before reading this thread, and thought it would be cool if:

• Each team could design a control system from the ground up
• FIRST would give teams a protocol to confrom to for recieveing FMS messages, and the team could write their own driver stations
• The only req'd hardware would be some sort of remotely controllable POWER kill switch that the scoring table could use to actually cut power to the robot
• FIRST could provide an out of the box solution as an option, but teams could commercialize their control systems or design their own if they so chose

I understand most of this is probably not possible for one reason or another (mainly safety, and I think too many robots would get bypassed, and there would be a lack of support staff, since every robot could be different), but, it does seem like something that would be a lot of fun for the Control System guys on each team to implement, and probably gives more real world experience with Control System Design.

- Oliver

Re: Control System Design Contest Proposal
 

While I understand the focus FIRST puts on safety I don't feel it's the greatest impediment to what you describe at all. In fact, most of the likely injuries you might sustain are similiar to those we already can experience if we don't put safety first. Since you aren't suggesting adding additional mechanical risks directly to the systems, I foresee that perhaps the additional safety issues might be exposure to chemicals common to the photographic methods of making printed circuit boards (photographic chemicals, etching solutions, tinning solutions or baths, acids...all of which can be found in your high school chemistry lab usually anyway) and cleaning the printed circuit boards after assembly (flux remover...luckily we don't use trichlor for that). Mechanical safety speaking the only thing that the existing electronics can achieve with relation to the robot's physical components is to stop or start attempting to move on field command and while that's a sort of safety feature on the field, let's be realistic that under non-field conditions the robot can move unexpectedly anyway and there are probably far fewer people there watching (less eyes, more risk). I will confirm that when I was in high school we manufactured printed circuits boards with Sharpie pens drawing on the copper clad boards, ferric chloride heated by a can of Sterno as an etching solution and a drill press (needless to say even my hobby process of making printed circuit boards has dramatically improved on that).

The safety issue fully considered for relevance. I think anything that requires electronics design, production and assembly would likely have these issues:

1. This would require a full circullum of education that might require at least 1 year to provide, not 6 weeks. You must assume a common demoninator of experience with this sort of thing. I'm all for the commitment frankly, but we need to be realistic about the time frame.

2. This might require the handling of additional chemicals and therefore the disposal of said chemicals which could be a regulatory issue (I know for example that my college no longer makes printed circuit boards because of the disposal costs). Course you could just send them out, but that takes at least 1 week generally or the costs go way up.

3. You touched on this already so I'll expand on it. This will make the rules more complicated and the review of the robot's compliance more difficult. Essentially the reviewers will be faced with the need to analyze your circuits. Not sure how much a problem that might be. Perhaps that could be dealt with by early submission of the schematics to some extent.

4. Even assembly in today's environment can be a bit of an issue. We are no longer in the days were everything is through hole printed circuit boards. Today surface mount is most common (except in military and aerospace use where it depends on some factors). Therefore you'll see teams with the need of tools to assemble surface mount printed circuit boards. Sure there are do-it-yourself solutions but all resources like that take up space, take up finanical capacity and create a division of capability. So one needs to consider that factor even if we all share openly.

5. I'm not too terribly concerned that we can all hack up powerful computing solutions. Frankly, the community beyond FIRST is extremely adept at coopting technology. In point of fact, the most common coopts tend to revolve about the programming aspect not the actual manufacturing that is common to electronics. For example, that is why we often see communities build up around Arduino boards, which really, are just carrier boards for Atmel microcontrollers. People can just go buy the Arduino carrier boards, they therefore avoid much of those electronics. However, once they try to interface that assembly to the real world that avoidance can be a major problem. I am concerned, in essence, that many teams lack the knowledge and experience to properly design functional and half-way reliable power controlling systems for motors. It's not a trivial effort. There are many factors one must fully consider. Take for example the issues teams face while implementing the Jaguars, the reaction to the challenge of doing that, and magnify that a few fold.

I will say that the power electronics issues might be mitigated by the availability of various speed controls as we have now. This introduces a set of known limits on the amount of power that can be delivered to an electromechanical actuator. I am all for that if that is the solution. This is to say not just one choice of speed controls and switching devices but a wide selection. Then if teams are up to this challenge of making their own power electronics, and willing to suffer the burden of manufacturing (like WildStang and the swerve drives), the whole community can benefit without creating a difficult situation for new teams to compete within (new teams are already really in a mechanical arms race with the existing teams as the existing teams are more likely to have full machine shops, a programming arms race as existing teams have already dealt with this challenge and a CAD/CAM arms race as the existing teams have probably at least touched on the effort). The key point being to present the idea for review and approval to the long list of available approved solutions we can pull from in advance so they can be bought, built (if the design is 'open-sorurce') or put in the kit of parts.

Re: Control System Design Contest Proposal
 

Everyone has a classmate, whats wrong with using that as the brains. Ethernet to a radio and some kind of pwm breakout/analog & digital IO (maybe done through USB?) and your set...battery just powers motors and the such.

EDIT: Second thought, that thing is so slow.. but the general idea of a laptop controller could work?

Re: Control System Design Contest Proposal
 

classmate = atom processor = (wish we had a barfing smilie)

Re: Control System Design Contest Proposal
 

There's no reason you can't use the laptop as the brains and several projects outside of FIRST do just that. However, the issue is that the PC is still basically an interrupt driven device and it's full of software emulated hardware pushing down on it's CPU in current generations.

The issue becomes that using the PC in realtime control applications can be tricky. So the solution is usually to make the peripherals smarter. At some point when you hook up a powerful microcontroller to buffer events for the PC (or even to handle the USB communication requirements) you've done what I already intended with the Parallax Propellers. You've driven a purpose built control system with a generic computing device to gain the benefits of both and overcome the limits of either alone.

Re: Control System Design Contest Proposal
 

In all fairness the newer Intel Atoms are much quicker than the older. We originally tested these ideas last year with the Dell Mini 9 that came with a miniPCI SSD and a single core Atom. It was actually able to process video but it did struggle especially with more than one webcam attached.

We have a dual core mobile AMD in the current netbook. It's quicker, but comparing it to for example an Intel I7 wouldn't be fair at all. It's powerful enough for the job and cheap enough to be under the cost requirements.

Re: Control System Design Contest Proposal
 

I would say a better radio is on my wish list. I liked the gaming adapters, but I like having a built in hub more. I also like the current system the way it is. Of course, it has some flaws (as evidenced by the Einstein report). All together though, it is pretty bulletproof.

As for boot times, the cRIO comes up to vxWorks in less than 20s, maybe 5s for labview RT, and then it's the bloat of your own code slowing it down...
Slowness aside, the cRIO is an FPGA! It has hardware counters and tons of other cool stuff, so I think it is way better than the IFI stuff. As for rookies being able to run with it, assuming you read the help file that is there when you load labview, a rookie could be running inside of 10 minutes.

Re: Control System Design Contest Proposal
 

the cRIO has an FPGA. it also has a CPU.