|
Re: Comments/Complaints on NI control system
@Kevin:
I can see your advantages to the new control system over the IFI processor, but I have several more comments:
1. I use probes all the time. I often crash Labview trying to open probes right after downloading, which is really annoying.
2. The IFI processor had 6 hardware interrupts, enough for 2 1x and 4 2x encoders or less with different decoding. The new processor has 8 hardware counters, but 4x decoding takes two counters. Not a big improvement, but no more ISRs
3. Sampling a gyro from Process_Data_From_Master_uP seems to have enough resolution and speed for everything to work fine.
4. I agree on the Jaguars, although the jaguars are actually more powerful than the entire IFI processor. However, the "safety" features included (shutdowns and lockouts on small errors) sent us to Victors this year.
5. I like the more IO but not the way the IO is handled - especially how the whole system has max. 7 power feeds to a whole bunch of separate boards on a whole bunch of separate modules on a cRio chassis. It could be a little more integrated.
6. I like the Dashboard, but the camera comm seems to cause problems with robot comm so I don't like camera comm.
7. I have several uint8 and uint16's in our robot, and typecasts associated with them. Most of them are involved in kicker set distance, as it prefers doing math in feet.
8. I often do run stuff by pressing the play button. And it takes me around 20 seconds to download over wireless, but using controls saves a bit of time.
9. It looks to me like the new PD board is quite a bit larger than the single MAXI block and ato6 panel on BuzzXIII, and a MAXI panel and ATO panels fit much more nicely into most of our framing. I also hate WAGO connectors because I am always loosing the WAGO tools and every little screwdriver we have, and the ability to get enough space on the side of the PD board to fit the WAGO tool in is often not enough. It does weigh less, which is nice.
10.Since most of our wiring is crammed around the Digital Sidecar, it ends up having twice as much IO in half the space (although it is burried deep in the belly of the robot, not visible remotely)
11. The LabVIEW splash screen dosen't even fit on the Classmate. I tried developing on it. The keyboard is just too small. I like the attempt of FIRST, but not the laptop.
12. Although I do not miss the analog joysticks, I do miss the raw analog IO. The new Cypress board is probably the single thing I hate most about the new system, since it A. runs on 3.3v, and especially B. the Driver Station has many issues finding it when combined with FMS.
As for advantages, the big ones I have that change the most, not including language.
1. Realtime trig without lookup tables
2. Floating-point math
3. Virtual multithreading
4. That's about it.
As for my autonomous example, I have found myself in many situations at competitions where there is a minor bug in autonomous, such as going a little bit too far or kicking a little too high, which is caused by a change in the reaction of something such as the kicker as it is worn in, and I must do a full deploy since it will be used on the field.
@everyone:
Many people probably see this thread as a request for the IFI processor back. That is not my intentions. I am saying that, while the cRio and associated control system has many bugs that the IFI system dosen't, neither one is perfect. It would be nice if only we could have a control system that was as fast, small, light, and reliable as the IFI system but more powerful. We don't really need the power of the 400mhz PowerPC, but having floating point math and LabVIEW really helps alot. If having a large several-pound cRio with many times the necessary power is the solution, then so be it. Just make the rest of the system work as well as it does. Having a dedicated driver station dosen't run Windows, lockout users after every match, and actually finds all of its inputs every time would be a nice start, followed by faster download/bootup times and more reliable radios. And maybe a solution to those ejecting analog modules other than glue.
__________________
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
|