Go to Post A bunch of kids in prom dresses staring through telescopes must have been quite a sight! - BlondeNerd [more]
Home
Go Back   Chief Delphi > Technical > Control System
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rate Thread Display Modes
  #16   Spotlight this post!  
Unread 03-03-2012, 22:57
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,622
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Control System Design Contest Proposal

Quote:
Originally Posted by Greg McKaskle View Post
I'm doing my best to follow this thread, and I may ask clarifying questions or point things out from time to time.

Logging was mentioned. The DS now has a Charts tab that displays the packet loss and trip time for communications -- same as the field has. It displays CPU usage, RAM, flash, and system voltage. It doesn't have any current data available to log. The robot flash is capable of logging info, but I'm not sure how much data or what data should be logged by default.

The DS also logs the mode that the field or DS asked to be run and if the robot code is instrumented, it logs what code actually ran on the robot.

The DS data is saved on the DS and a log viewer is in the Program Files/FRC Driver Station folder.

Greg McKaskle
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.
Reply With Quote
  #17   Spotlight this post!  
Unread 04-03-2012, 09:13
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,752
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
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
Reply With Quote
  #18   Spotlight this post!  
Unread 04-03-2012, 09:40
Foster Foster is online now
Engineering Program Management
VRC #8081 (STEMRobotics)
Team Role: Mentor
 
Join Date: Jul 2007
Rookie Year: 2005
Location: Delaware
Posts: 1,393
Foster has a reputation beyond reputeFoster has a reputation beyond reputeFoster has a reputation beyond reputeFoster has a reputation beyond reputeFoster has a reputation beyond reputeFoster has a reputation beyond reputeFoster has a reputation beyond reputeFoster has a reputation beyond reputeFoster has a reputation beyond reputeFoster has a reputation beyond reputeFoster has a reputation beyond repute
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
__________________
Foster - VEX Delaware - 17 teams -- Chief Roboteer STEMRobotics.org
2010 - Mentor of the Year - VEX Clean Sweep World Championship
2006-2016, a decade of doing VEX, time really flies while having fun
Downingtown Area Robotics Web site and VEXMen Team Site come see what we can do for you.
Reply With Quote
  #19   Spotlight this post!  
Unread 04-03-2012, 10:01
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,752
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
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
Reply With Quote
  #20   Spotlight this post!  
Unread 04-03-2012, 10:23
Unsung FIRST Hero
Al Skierkiewicz Al Skierkiewicz is offline
Broadcast Eng/Chief Robot Inspector
AKA: Big Al WFFA 2005
FRC #0111 (WildStang)
Team Role: Engineer
 
Join Date: Jun 2001
Rookie Year: 1996
Location: Wheeling, IL
Posts: 10,792
Al Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond reputeAl Skierkiewicz has a reputation beyond repute
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
__________________
Good Luck All. Learn something new, everyday!
Al
WB9UVJ
www.wildstang.org
________________________
Storming the Tower since 1996.
Reply With Quote
  #21   Spotlight this post!  
Unread 04-03-2012, 11:35
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,752
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
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
Reply With Quote
  #22   Spotlight this post!  
Unread 20-03-2012, 09:18
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,622
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
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.

Last edited by techhelpbb : 20-03-2012 at 09:25.
Reply With Quote
  #23   Spotlight this post!  
Unread 20-03-2012, 22:31
linuxboy linuxboy is offline
Registered User
AKA: Oliver Graff
FRC #3780
Team Role: Alumni
 
Join Date: Nov 2010
Rookie Year: 2009
Location: MI, USA
Posts: 217
linuxboy has much to be proud oflinuxboy has much to be proud oflinuxboy has much to be proud oflinuxboy has much to be proud oflinuxboy has much to be proud oflinuxboy has much to be proud oflinuxboy has much to be proud oflinuxboy has much to be proud oflinuxboy has much to be proud of
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
Reply With Quote
  #24   Spotlight this post!  
Unread 21-03-2012, 08:01
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,622
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Control System Design Contest Proposal

Quote:
Originally Posted by linuxboy View Post
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
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.

Last edited by techhelpbb : 21-03-2012 at 21:44.
Reply With Quote
  #25   Spotlight this post!  
Unread 27-03-2012, 02:17
Brandon_L Brandon_L is offline
Someone told me there was food here
AKA: Brandon Liatys
FRC #2180 (Zero Gravity)
Team Role: Mentor
 
Join Date: Jan 2008
Rookie Year: 2007
Location: Newark, NJ
Posts: 1,206
Brandon_L has a reputation beyond reputeBrandon_L has a reputation beyond reputeBrandon_L has a reputation beyond reputeBrandon_L has a reputation beyond reputeBrandon_L has a reputation beyond reputeBrandon_L has a reputation beyond reputeBrandon_L has a reputation beyond reputeBrandon_L has a reputation beyond reputeBrandon_L has a reputation beyond reputeBrandon_L has a reputation beyond reputeBrandon_L has a reputation beyond repute
Re: Control System Design Contest Proposal

Quote:
Originally Posted by techhelpbb View Post
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.
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?
__________________
FRC 2495 - Hamilton West Robotics [2007-2014] - whats a..."hive mind"?
FRC 3929 - Atomic Dragons [2012-2013]
FRC 2180 - Zero Gravity [2017-]

Just trying to collect all the possible team colors
Reply With Quote
  #26   Spotlight this post!  
Unread 27-03-2012, 03:50
Schnabel's Avatar
Schnabel Schnabel is offline
Seriously I'm almost never serious!
AKA: Eric Schnabel
FRC #0469
Team Role: Mentor
 
Join Date: Apr 2006
Rookie Year: 2003
Location: Troy, MI
Posts: 1,174
Schnabel has a reputation beyond reputeSchnabel has a reputation beyond reputeSchnabel has a reputation beyond reputeSchnabel has a reputation beyond reputeSchnabel has a reputation beyond reputeSchnabel has a reputation beyond reputeSchnabel has a reputation beyond reputeSchnabel has a reputation beyond reputeSchnabel has a reputation beyond reputeSchnabel has a reputation beyond reputeSchnabel has a reputation beyond repute
Re: Control System Design Contest Proposal

Quote:
Originally Posted by Brandon_L View Post
Everyone has a classmate, whats wrong with using that as the brains.
classmate = atom processor = (wish we had a barfing smilie)
__________________
I win! XD
Reply With Quote
  #27   Spotlight this post!  
Unread 27-03-2012, 06:33
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,622
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Control System Design Contest Proposal

Quote:
Originally Posted by Brandon_L View Post
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?
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.
Reply With Quote
  #28   Spotlight this post!  
Unread 27-03-2012, 06:37
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,622
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Control System Design Contest Proposal

Quote:
Originally Posted by Schnabel View Post
classmate = atom processor = (wish we had a barfing smilie)
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.
Reply With Quote
  #29   Spotlight this post!  
Unread 20-07-2012, 16:12
MAldridge's Avatar
MAldridge MAldridge is offline
Lead Programmer
AKA: Rube #1
FRC #0418 (LASA Robotics)
Team Role: Programmer
 
Join Date: Jan 2011
Rookie Year: 2010
Location: Austin
Posts: 117
MAldridge will become famous soon enoughMAldridge will become famous soon enough
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.
__________________
'Why are you a programer?' --Team Captain
'Because the robot isn't complicated enough!' --Me
Reply With Quote
  #30   Spotlight this post!  
Unread 20-07-2012, 16:19
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,097
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Control System Design Contest Proposal

Quote:
Originally Posted by MAldridge View Post
the cRIO is an FPGA
the cRIO has an FPGA. it also has a CPU.


Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 05:52.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


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