Go to Post What we may be looking at is a confusing situation and that can be confusing. - JaneYoung [more]
Home
Go Back   Chief Delphi > Technical > Technical Discussion
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rating: Thread Rating: 19 votes, 5.00 average. Display Modes
  #61   Spotlight this post!  
Unread 03-05-2013, 19:29
Oblarg Oblarg is offline
Registered User
AKA: Eli Barnett
FRC #0449 (The Blair Robot Project)
Team Role: Mentor
 
Join Date: Mar 2009
Rookie Year: 2008
Location: Philadelphia, PA
Posts: 1,113
Oblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond repute
Re: NI releasing/designing new controller for FRC

Can they just make an arduino a FRC-legal robot controller and be done with it?
__________________
"Mmmmm, chain grease and aluminum shavings..."
"The breakfast of champions!"

Member, FRC Team 449: 2007-2010
Drive Mechanics Lead, FRC Team 449: 2009-2010
Alumnus/Technical Mentor, FRC Team 449: 2010-Present
Lead Technical Mentor, FRC Team 4464: 2012-2015
Technical Mentor, FRC Team 5830: 2015-2016
  #62   Spotlight this post!  
Unread 03-05-2013, 20:24
mman1506's Avatar
mman1506 mman1506 is offline
Hater of Tiny Molex Connectors
AKA: Marcus Quintilian
no team (WARP7)
Team Role: Alumni
 
Join Date: Mar 2012
Rookie Year: 2012
Location: Toronto
Posts: 806
mman1506 has a reputation beyond reputemman1506 has a reputation beyond reputemman1506 has a reputation beyond reputemman1506 has a reputation beyond reputemman1506 has a reputation beyond reputemman1506 has a reputation beyond reputemman1506 has a reputation beyond reputemman1506 has a reputation beyond reputemman1506 has a reputation beyond reputemman1506 has a reputation beyond reputemman1506 has a reputation beyond repute
Re: NI releasing/designing new controller for FRC

Quote:
Originally Posted by Oblarg View Post
Can they just make an arduino a FRC-legal robot controller and be done with it?
As Arduino lover myself I can say that would suck. The C-Rio's FPGA is much faster than a Atmega 2560. You would not be able to do on-board vision processing and code would have to be optimized to run quickly. It also would alienate all current FRC programmers (Arduino code is not C++, BTW)
__________________
2014-2015: FRC 865 Warp7 Team Captain
2016: FRC 865 Mentor

2017: Free Agent Mentor, Inspector
  #63   Spotlight this post!  
Unread 04-05-2013, 02:42
Hypnotoad's Avatar
Hypnotoad Hypnotoad is offline
Junior Assistant Secretary of Moon
no team
Team Role: Programmer
 
Join Date: Feb 2012
Rookie Year: 2011
Location: California
Posts: 114
Hypnotoad is infamous around these partsHypnotoad is infamous around these partsHypnotoad is infamous around these partsHypnotoad is infamous around these partsHypnotoad is infamous around these partsHypnotoad is infamous around these parts
Re: NI releasing/designing new controller for FRC

You can't do proper vision processing on a crio anyways, so nothing is lost by using an arduino. I ended up just doing it on the driver station since the image had to go there at some point anyways.
__________________
The following sentence is true.
The preceding sentence is false.
This sentence is false.
This signature is false.
My teeth are false.
  #64   Spotlight this post!  
Unread 04-05-2013, 08:44
Gdeaver Gdeaver is offline
Registered User
FRC #1640
Team Role: Mentor
 
Join Date: Mar 2004
Rookie Year: 2001
Location: West Chester, Pa.
Posts: 1,370
Gdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond repute
Re: NI releasing/designing new controller for FRC

So a little 8 bit controller with no fpu, no fpga, no native lan, no RTOS, and etc etc etc, can replace what we have now. Every team has the expertise to implement a low level ISR and can drop down and write directly to the hardware at the register level when needed? Your going to take a 9th grader and throw that at him? I think allot of people do not realize the power we now have available to us. Even the old IFI controller had two 8 bit pics in it. The vexters at least have an arm chip to play with. The only way teams accomplished complex things with the old IFI solution was some excellent low level code done by Kevin Watson. I can't believe the number of people that want to go backwards. There is a place for an Arduino in First. One of our students used an Uno and some leds to make a heads up targeting system for the driver. Got an award for it. We are using a Uno to read a 3 axis accelerometer, gyro, and magnetometer to make an IMU. Reading the 9 16 bit values over I2C and doing a bunch of triangle math is saturating the Uno. Yes, Arduinos do have a place in first. They make good coprocessors.
  #65   Spotlight this post!  
Unread 04-05-2013, 12:41
dellagd's Avatar
dellagd dellagd is offline
Look for me on the field!
AKA: Griffin D
FRC #2590 (Nemesis) #2607 (The Fighting Robovikings)
Team Role: Mentor
 
Join Date: Sep 2011
Rookie Year: 2011
Location: PA
Posts: 890
dellagd has a reputation beyond reputedellagd has a reputation beyond reputedellagd has a reputation beyond reputedellagd has a reputation beyond reputedellagd has a reputation beyond reputedellagd has a reputation beyond reputedellagd has a reputation beyond reputedellagd has a reputation beyond reputedellagd has a reputation beyond reputedellagd has a reputation beyond reputedellagd has a reputation beyond repute
Re: NI releasing/designing new controller for FRC

Correct me if Im wrong, but does that poster say USB will be available on the "Athena"?

Naturally, hoping this unlocks the possibility of using the kinect without any extra computing hardware on the robot.
__________________
Check out some cool personal projects in computers, electronics, and RC vehicles on my blog!

2016 MAR DCMP Engineering Excellence Award
2016 MAR Westtown Innovation in Control Award
2016 MAR Hatboro-Horsham Industrial Design Award
2015 Upper Darby District Winners - Thanks 225 and 4460!
2015 Upper Darby District Industrial Design Award
2015 Hatboro-Horsham District Winners - Thanks 2590 and 5407!
2014 Virginia Regional Winners - Thanks so much 384 and 1610, I will never forget that experience!
2014 Virginia Quality Award
2014 MAR Bridgewater-Raritan Innovation in Control Award
2014 MAR Hatboro-Horsham Gracious Professionalism Award
2013 MAR Bridgewater-Raritan Innovation in Control Award
2012 MAR Lenape Quality Award
  #66   Spotlight this post!  
Unread 04-05-2013, 13:40
gluxon's Avatar
gluxon gluxon is offline
\n
AKA: Brandon Cheng
FRC #0178 (The 2nd Law Enforcers)
Team Role: Leadership
 
Join Date: Apr 2012
Rookie Year: 2011
Location: Connecticut
Posts: 65
gluxon has a spectacular aura aboutgluxon has a spectacular aura aboutgluxon has a spectacular aura about
Re: NI releasing/designing new controller for FRC

Quote:
Originally Posted by dellagd View Post
Correct me if Im wrong, but does that poster say USB will be available on the "Athena"?

Naturally, hoping this unlocks the possibility of using the kinect without any extra computing hardware on the robot.
It does, and I talked to another person earlier in the year that claimed it did (yes, I would say he was reliable). Kinect's USB protocol is pretty open, so even if WPILib doesn't support it in 2015, I bet it will in a later year or someone will write a library to communicate with it.
  #67   Spotlight this post!  
Unread 04-05-2013, 15:39
Hjelstrom's Avatar
Hjelstrom Hjelstrom is offline
Mentor
FRC #0987 (High Rollers)
Team Role: Mentor
 
Join Date: Mar 2008
Rookie Year: 2005
Location: Las Vegas
Posts: 148
Hjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond reputeHjelstrom has a reputation beyond repute
Re: NI releasing/designing new controller for FRC

Quote:
Originally Posted by dellagd View Post
Correct me if Im wrong, but does that poster say USB will be available on the "Athena"?

Naturally, hoping this unlocks the possibility of using the kinect without any extra computing hardware on the robot.
agreed! This was a big hope i had for the next controller and it looks like it will be possible.
  #68   Spotlight this post!  
Unread 04-05-2013, 18:06
fb39ca4 fb39ca4 is offline
Registered User
FRC #1899
 
Join Date: Jan 2012
Location: Bellevue, WA
Posts: 195
fb39ca4 is a name known to allfb39ca4 is a name known to allfb39ca4 is a name known to allfb39ca4 is a name known to allfb39ca4 is a name known to allfb39ca4 is a name known to all
Re: NI releasing/designing new controller for FRC

How about something like a BeagleBone or UDOO? They both have the i/o capabilities of an Arduino, but also have 1Ghz ARM CPUs (quad core in the latter) and Ethernet.
  #69   Spotlight this post!  
Unread 04-05-2013, 21:46
mman1506's Avatar
mman1506 mman1506 is offline
Hater of Tiny Molex Connectors
AKA: Marcus Quintilian
no team (WARP7)
Team Role: Alumni
 
Join Date: Mar 2012
Rookie Year: 2012
Location: Toronto
Posts: 806
mman1506 has a reputation beyond reputemman1506 has a reputation beyond reputemman1506 has a reputation beyond reputemman1506 has a reputation beyond reputemman1506 has a reputation beyond reputemman1506 has a reputation beyond reputemman1506 has a reputation beyond reputemman1506 has a reputation beyond reputemman1506 has a reputation beyond reputemman1506 has a reputation beyond reputemman1506 has a reputation beyond repute
Re: NI releasing/designing new controller for FRC

Quote:
Originally Posted by fb39ca4 View Post
How about something like a BeagleBone or UDOO? They both have the i/o capabilities of an Arduino, but also have 1Ghz ARM CPUs (quad core in the latter) and Ethernet.
The problem with the beaglebone and others is that they do not have a Real time operating system. This means that there is a delay when inputting data and things don't always work in real time. This becomes an issue for safety and a number of other things as proccesing can become delayed as you can not expect it to processe an input in a certain time frame.

While they do have I/O doing something simple like PWM generation requires special scripting.
__________________
2014-2015: FRC 865 Warp7 Team Captain
2016: FRC 865 Mentor

2017: Free Agent Mentor, Inspector

Last edited by mman1506 : 04-05-2013 at 21:51.
  #70   Spotlight this post!  
Unread 05-05-2013, 06:34
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,624
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: NI releasing/designing new controller for FRC

Quote:
Originally Posted by mman1506 View Post
The problem with the beaglebone and others is that they do not have a Real time operating system. This means that there is a delay when inputting data and things don't always work in real time. This becomes an issue for safety and a number of other things as proccesing can become delayed as you can not expect it to processe an input in a certain time frame.

While they do have I/O doing something simple like PWM generation requires special scripting.
There was an alternative system that could handle that presented. What FIRST wanted was a company to be essentially already be in NI's/Vex's educational market with FIRST. So basically from the release date of the RFP to the time they made their decision you had to be in thriving production with a client base (less than 6 months).

I helped submit one of the bids and engineer the solution presented. The solution survived the bid. I would not waste this kind of time and money doing something like this if I did not have other plans for it (especially since it entailed writing a graphical language framework). I've not heard from the other team that put the Arduino Kickstarter up about my offer to simply hand them the same donation I gave them by the defunct Kickstarter.

Quote:
Originally Posted by Gdeaver View Post
So a little 8 bit controller with no fpu, no fpga, no native lan, no RTOS, and etc etc etc, can replace what we have now. Every team has the expertise to implement a low level ISR and can drop down and write directly to the hardware at the register level when needed? Your going to take a 9th grader and throw that at him? I think allot of people do not realize the power we now have available to us. Even the old IFI controller had two 8 bit pics in it. The vexters at least have an arm chip to play with. The only way teams accomplished complex things with the old IFI solution was some excellent low level code done by Kevin Watson. I can't believe the number of people that want to go backwards. There is a place for an Arduino in First. One of our students used an Uno and some leds to make a heads up targeting system for the driver. Got an award for it. We are using a Uno to read a 3 axis accelerometer, gyro, and magnetometer to make an IMU. Reading the 9 16 bit values over I2C and doing a bunch of triangle math is saturating the Uno. Yes, Arduinos do have a place in first. They make good coprocessors.
I've been programming since before I was 10 and one of my very first embedded platforms was the Intel 8051 and yes I spent many an hour writing assembly interrupt service routines. So yes *if* someone had to do it there are people out there that could step up with examples as you also pointed out.

That being said not every processor needs to have interrupts. In point of fact I helped present a non-interrupt centric solution to FIRST for this RFP. You could put interrupt capable devices into the system but you did not need to. It worked by basically polling which normally would be very resource intense but you could cheaply put so much processing into what we presented it was not an issue. There was still plenty of opportunity to implement custom logic via programmable logic in the system if a very sensitive timing constraint arose.

Again neither here not there, The system we proposed is currently being prepared for use in a non-FIRST commerical hardened real time application.

Last edited by techhelpbb : 05-05-2013 at 06:50.
  #71   Spotlight this post!  
Unread 14-06-2013, 01:21
dtengineering's Avatar
dtengineering dtengineering is offline
Teaching Teachers to Teach Tech
AKA: Jason Brett
no team (British Columbia FRC teams)
Team Role: Mentor
 
Join Date: Jan 2005
Rookie Year: 2004
Location: Vancouver, BC
Posts: 1,833
dtengineering has a reputation beyond reputedtengineering has a reputation beyond reputedtengineering has a reputation beyond reputedtengineering has a reputation beyond reputedtengineering has a reputation beyond reputedtengineering has a reputation beyond reputedtengineering has a reputation beyond reputedtengineering has a reputation beyond reputedtengineering has a reputation beyond reputedtengineering has a reputation beyond reputedtengineering has a reputation beyond repute
Re: NI releasing/designing new controller for FRC

Quote:
Originally Posted by Gdeaver View Post
So a little 8 bit controller with no fpu, no fpga, no native lan, no RTOS, and etc etc etc, can replace what we have now. ..... Yes, Arduinos do have a place in first. They make good coprocessors.
Based on my observations for the majority of FRC teams an Arduino... and I mean an UNO, not even a Mega or Due, would be more than sufficent to meet their programming needs.

The vast majority of teams would have difficulty convincing me that they really needed more processing power than a Due could provide.

Back in my day a 1MHz 6510 CPU was just a good excuse to learn some assembler! What do you kids need all this new-fangled gadgetry for anyway? It just makes you lazy! Sheesh.... grump grump grump.

(Where's a balding, greying smiley when you need one?!?)

Jason
  #72   Spotlight this post!  
Unread 14-06-2013, 06:24
Michael Hill's Avatar
Michael Hill Michael Hill is online now
Registered User
FRC #3138 (Innovators Robotics)
Team Role: Mentor
 
Join Date: Jul 2004
Rookie Year: 2003
Location: Dayton, OH
Posts: 1,580
Michael Hill has a reputation beyond reputeMichael Hill has a reputation beyond reputeMichael Hill has a reputation beyond reputeMichael Hill has a reputation beyond reputeMichael Hill has a reputation beyond reputeMichael Hill has a reputation beyond reputeMichael Hill has a reputation beyond reputeMichael Hill has a reputation beyond reputeMichael Hill has a reputation beyond reputeMichael Hill has a reputation beyond reputeMichael Hill has a reputation beyond repute
Quote:
Originally Posted by dtengineering View Post
Based on my observations for the majority of FRC teams an Arduino... and I mean an UNO, not even a Mega or Due, would be more than sufficent to meet their programming needs.

The vast majority of teams would have difficulty convincing me that they really needed more processing power than a Due could provide.

Back in my day a 1MHz 6510 CPU was just a good excuse to learn some assembler! What do you kids need all this new-fangled gadgetry for anyway? It just makes you lazy! Sheesh.... grump grump grump.

(Where's a balding, greying smiley when you need one?!?)

Jason
Except for that whole image processing thing...or all of the libraries that are needed. Arduinos don't have THAT much memory to put robust enough code on.

Think of all the stuff WPILib has in it. None of that would be available just because of memory restrictions.
  #73   Spotlight this post!  
Unread 14-06-2013, 12:59
Jim Zondag's Avatar
Jim Zondag Jim Zondag is offline
Team Leader
FRC #0033 (Killer Bees)
Team Role: Engineer
 
Join Date: Nov 2001
Rookie Year: 1997
Location: Auburn Hills
Posts: 317
Jim Zondag has a reputation beyond reputeJim Zondag has a reputation beyond reputeJim Zondag has a reputation beyond reputeJim Zondag has a reputation beyond reputeJim Zondag has a reputation beyond reputeJim Zondag has a reputation beyond reputeJim Zondag has a reputation beyond reputeJim Zondag has a reputation beyond reputeJim Zondag has a reputation beyond reputeJim Zondag has a reputation beyond reputeJim Zondag has a reputation beyond repute
Re: NI releasing/designing new controller for FRC

Quote:
Originally Posted by dtengineering View Post
Back in my day a 1MHz 6510 CPU was just a good excuse to learn some assembler! What do you kids need all this new-fangled gadgetry for anyway?
My first robot used an Intel 8748 as the CPU. 64 Bytes of RAM...WooHoo.
This was cutting edge at the time.



Despite the modest hardware, we could do some pretty cool stuff...Sonar ranging, odometry, programmable course input, full autonomous functionality, etc. This was more complex than many FRC robots today.
__________________
"To learn what is possible, we must attempt the impossible." Arthur C. Clarke
  #74   Spotlight this post!  
Unread 14-06-2013, 13:14
nuttle nuttle is offline
Registered User
AKA: Allen Nuttle
FRC #4080
Team Role: Mentor
 
Join Date: Mar 2010
Rookie Year: 2009
Location: United States
Posts: 104
nuttle has much to be proud ofnuttle has much to be proud ofnuttle has much to be proud ofnuttle has much to be proud ofnuttle has much to be proud ofnuttle has much to be proud ofnuttle has much to be proud ofnuttle has much to be proud of
Re: NI releasing/designing new controller for FRC

Sorry this is a little long, it is basically my thoughts on the control system. I want to get this out in case it is helpful in some way or stimulates discussion. I hope this isn't too late to be relevant.


Personally, I'd like to see the control system become more open. This could only happen if safety was ensured in a way that couldn't be compromised and if it didn't complicate things for teams that didn't want or need to make things more involved.

The main requirement around safety is having a fail-safe way to guarantee all output devices go to a known state when there is loss of contact with the field or driver station or when either of these things is used to disable a robot. Any sort of failure between the field/driver station and the output device must result in the output device becoming disabled.

To keep things simple, you really want something close to plug-n-play for a minimal robot control system, but that doesn't constrain what you can do to expand the system. This has parallels to how some teams do vision processing, using the CRIO, adding an onboard dedicated system to do this, or running this on the driver station (or simply not doing it at all).


I'd approach this by having smart modules that communicate over CAN (I know there are a lot of people who are uneasy about CAN, but this is more a reflection of what has been available in FIRST rather than the technology itself -- another topic, as another technology could be substituted if it were determined to be a better fit).

The CAN-based pneumatics module presented by CTR is a good example of this approach. A big piece of the puzzle here would be an excellent replacement for the Jaguar, a CAN-based smart motor controller. More on this later...

To round things out, you'd also have either something like a CAN-based digital side car or perhaps a CAN-based PWM output module and another module to provide general purpose digital I/O and analog input.


The next piece of the puzzle would be something similar to the 2CAN, but with a little more to it. On the Ethernet side, this would connect to the radio and provide bandwidth monitoring and management (including prioritization, particularly for upstream data) and would have several ports for local Ethernet on the robot (camera, PC, NI Athena, Arduino, etc.).

It would also be the interface to CAN (like the 2CAN) but would additionally provide the safety function and an output for the robot signal light. This would be totally closed with no user code. Safety heartbeats would be sourced from the driver station (or the field through the driver station) and flow via CAN to all control modules, probably using a dedicated line, as described further on for the smart motor controller.

This would allow the control module firmware on the smart modules to be opened up. A minimal system might only have a radio, the 2CAN-like router/safety device, and some number of controllers, plus power (you might even have power for the radio supplied by the router/safety device). The driver station could send commands that would be routed over CAN to the control modules to run such a minimal robot.

A more typical configuration would have a compute device of some sort (NI) and this would communicate with the driver station and the control modules. Other CAN-based modules that might be nice additions are an IMU and a high-current LED driver. The driver station would remain NI and not need to be changed much. In fact, the most typical robot configuration would be essentially as it is today, except that the I/O capabilities on the NI really wouldn't have to be used (they certainly could be though).


I'll skip to some detail on the smart motor control module, as this illustrates how the safety function is implemented. Again, sorry about the length! The rest of this is fairly detailed proposal for what is essentially an improved Jaguar (including more detail on how safety is provided), starting with some requirements:

- Master/slave mode where more than one motor can effectively be run by a single controller acting as the master and sending messages that determine H-bridge duty-cycle for slave(s) (for things like drivetrain with more than one motor being controlled using a single encoder for velocity or position feedback, avoiding the need to send encoder data to more than one controller; this depends on safety scheme described below to be safe/legal)

- Return position, velocity, and acceleration and allow these to be used for closed-loop control, same for output current and voltage (return only of input voltage and temp. as well)

- Properly handle indexed encoder (for position control with index providing position reference)

- Traction control (limited acceleration, cut power when slipping/too much acceleration or pulse power similar to ABS braking on command or when slipping)

- Can replace Spike relay module (might not be cost-effective, but should be able to control same loads and legal in these uses, including replacing two relays when reverse direction is not needed)

- Non-volatile configuration (remembers not only CAN ID but also mode and various settings so these are there from power up or reset; this replaces configuration jumpers)

- Setting that governs current limit that is based on list of legal motors (plus option for manual specification of this value, or no limit -- this protects the motors, the controller handles anything up to what it takes to trip the breaker)

- Consider reverse-polarity protection

- Support PID and bang-bang control algorithms (possibly others as well)

- Good status indicators (LEDs)

- Personally, I'd like to see the firmware opened up (again, safety considerations would require care here, see below)

- Really nice doc on theory, how it works, etc. (to educate and inspire users, plus allow people to work on the firmware)

- Consider using WAGO connectors (to match PDB)


Some possible parts:

- Infineon TLE7182EM H-bridge controller (there's a nice evaluation board available for this part and also some great FETs and other parts from this supplier)

- Fairchild FOD0710 Optoisolator (for any input that could involve a ground loop, not needed for sensors that only connect to controller -- used for the safety input, for example)

- LSI/CSI LS7366R Encoder handling with SPI I/F

- I didn't get to the point of selecting uC, but PSoC or uC with support for generating PWM, CAN, and SPI would be a good fit, also needs inputs for sensors, etc. (preceding part handles encoder, leaving limit switch inputs, potentiometer, and internal needs -- I used something more expensive and powerful than required in a prototype, there is a lot of flexibility here, something like Microchip dsPIC30F4012 would do nicely)


Other thoughts:

- Consider not including PWM input (if other controllers in product line have this covered)

- Safety uses H/W watchdog chip and resets H-bridge controller only (but not uC, or just gates off H-bridge inputs) and uses either the PWM input only for heartbeat, or possibly include a dedicated safety line on the CAN cable for this purpose (this is the cleaner/preferred approach, the safety line just carries a square wave from the router/safety device that directly feeds the H/W watchdog, causing it to trip if the signal is lost for any reason)

- There are parts that do H/W watchdog, power on reset, provide power for uC and external sensors, etc. (automotive parts are a good fit because they run on 12V, are high volume, and solve the a similar set of problems in a robust way)


Thanks for reading!

Last edited by nuttle : 14-06-2013 at 21:41. Reason: some minor clarifications
  #75   Spotlight this post!  
Unread 14-06-2013, 14:31
apalrd's Avatar
apalrd apalrd is offline
More Torque!
AKA: Andrew Palardy (Most people call me Palardy)
VRC #3333
Team Role: College Student
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Auburn Hills, MI
Posts: 1,347
apalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond repute
Re: NI releasing/designing new controller for FRC

The only reason it's so darn hard to do stuff now is because of inefficiency in the current system - The WPIlib in LabVIEW is so unoptimized that it's nearly impossible to run code that uses IO calls faster than 20ms task time without saturating the CPU.

The fact that we're currently saturating a 400mhz PowerPC amazes me. I don't like the idea that we should just throw more power at it to deal with it, since there's no reason to need anything near a 400mhz PowerPC.

I have a project I'm working on right now that uses a bunch of unoptimized floating-point math, a whole bunch of interpolations, and runs in two high-speed tasks (TDC and 200hz - TDC is ~5ms at 12000rpm) plus a few CAN interrupts (Jaguars should learn about CAN interrupts...). Bandwidth on a 56mhz PowerPC (MPC536) is extremely low, last time I checked it was under 30%. PWM IO is done on a PWM/timer on-chip module (MIOS), angular IO and angular synchronization are done in another on-chip module (TPU) which I did not write code for, which is essentially an optimized match/compare/timer module with microcode engine to autonomously reschedule matches and trigger ISRs. Between the MIOS and TPU, all of the current FRC FPGA non-analog functionality could be implemented with similar host-side overhead. Code includes some high-speed PI and bang-bang controllers, and LOTS of table interpolations. I did no real optimization on the math, it's about as much code/math as a complex FRC robot.
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor

"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack
Closed Thread


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 18:16.

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