Quote:
Originally Posted by Mark McLeod
I never noticed that, seeing as I was involved in three or four IFI emergency beta firmware debugging sessions in the middle of the season...
So soon we forget how many IFI Master Code upgrades we performed over the years. I remember version 15d...
Selective memory is a killer.
No system is perfect. What you should look for is corporate willingness to recognize and react quickly to solving issues when they do arise.
|
That's not what I was talking about. I am not referring to the
need to update firmware, but bugs in the firmware. I have no problem imaging the controller.
Let's look at some fictional robots:
Imagine you have a robot that has a driver joystick and an operator box, using the IFI control system. Suddenly, you plug it in to the Competition controller and BAM - ports 3 and 4 don't work, but ports 1 and 2 do? OH - you just have to power cycle it a few times the right way and all is well. That's what it's like with the Cypress board, except it takes a long time to power cycle since it runs Windows.
Now imagine you have another robot with an IFI controller, and it controls an apparatus that has a potentiometer for position sensing and a motor to move it. Now you drive over a bump, and suddenly all of your analog ports fall off. Now the robot is trying to kill itself because all of its sensors are gone. I have seen analog modules fall out of the cRio while going over a bump, even though they were completely inserted and latched into the cRio.
And lets compare two robots. Both have a slightly loose connection to their radio. This is a likely scenario with the 2009 Gaming adapters, since the power connection does not lock, but unlikely with the IFI system since all of the connections use DB9 connectors which have locking screws. One has the NI control system, one has the IFI control system. Both robots drive over a bump. Both loose connection. The robot with the IFI system will disable itself because it has lost comm, and try to communicate as soon as the radio is functional again. Within 5s of radio power-up, it is up and running again. However, the other robot will also disable itself, but since it dropped too many data packets while connected to the FMS, it will sit dead until somebody reboots it. Sucks for that robot.
And another comparison of robots. This time, both robots encountered an error and need to be rebooted. It doesn't matter what for, they just do. 5s after being booted, the IFI processor will find its OI if the OI is available and have finished initiating radio comm. As Greg measured, it takes the cRio ~30 seconds to boot. The IFI robot has already finished Autonomous mode and scored a few balls since the other robot is too busy booting up to play defense.
And then, the two robots have back-to-back matches. They must tether, boot, move an apparatus to be within the starting box, and change the battery in 5 minutes. The physical process of tethering takes aprox. 30 seconds each, plus boot up times, around 30s to move the apparatus, and a minute to change the battery. The NI-based robot also has to restart Driver Station since it is FMS locked, which takes around 1 min 15 secs. The IFI robot can be ready in 2 min 5 seconds, while it would take the other robot take 4 min 45 secs to do all of this.
Now look at what these two robots can do. Both have swerve drive, with feedback on the front and rear wheels independently. They react almost identically to driver input. There is a solid-color vision target in the game. The IFI processor uses its CMUcam Co-Processor to find it and drive to it. This causes almost no lag on its part. The cRio connects via Ethernet to its camera, downloads a new image, processes it, and drives to the target, while causing the swerve drive controls to freak out from the non-constant loop time (even though vision is running in a separate virtual thread). I have seen vision processing mess up PID calculations. That's exactly why we didn't use the camera in 2009 with our swerve drive.
And finally we will see what happens when the programmer must change a small variable in Autonomous mode. Since the IFI processor is programmed in MPLAB C, the programmer would have to change a variable or function call in the code. They would then have to compile the code, a process that takes around 10 seconds. They would have to plug a serial cable into the robot controller, and download the code. This download process takes around 15 seconds. They would then unplug their serial cable and press the RESET button. In 35 seconds, not including the time it takes to connect the serial cable, they are ready to go. With our other robot that has a cRio, the programmer makes the same function call change. He then builds the code, which using Greg's benchmarking would take around 2 minutes. He then must tether to the robot, which is not included in the time. He then must wait for the robot to boot up, a process which Greg claims takes 30 seconds. Then, he must Deploy his code. I have never ever seen my code download in 18 seconds, so here is my calculation for download time: aprox. 30 seconds to load code + 15 seconds to wait for cRio + 10 seconds to do something unknown before asking me to reboot. Total time: 55 seconds. After another reboot, that brings the grand total minor code change time for this robot with a cRio to 3 minutes 55 seconds. Unacceptable. That's 3 minutes 20 seconds more than the IFI processor, or a bit more than the time it takes to run one match, or a 671% increase.