![]() |
What was the hardest to program this year in Java?
I was going around, and I know that people make classes/interfaces for doing the bizzare things that are used frequently on their robots.
For me is was getting DigitalInputs working, to do that, I made this class: Code:
package com.shadowh511.mayor.inputs;Code:
Switch ballSwitch = new Switch(4);Code:
Switch ballSwitch = new Switch(4,4); |
Re: What was the hardest to program this year in Java?
For us it'd have been making our own Gyro code. We used three gyros on the robot and so had to make our own. It ended up being just as accurate as the WPI code and now we are adding some filtering to it to solve for irregularities.
|
Re: What was the hardest to program this year in Java?
I gave up on the gyro after 3 hours
|
Re: What was the hardest to program this year in Java?
I think the hardest part for us was working with the Cypress I/O board. I can't count the number of times I got the "Enhanced IO Missing" exception while trying to read inputs from that thing. It turns out you can't read them in robotInit() - you have to wait about a second for the board to be ready before attempting to read it.
|
Re: What was the hardest to program this year in Java?
I hated that too.
I used a seperate class for the cypress i/o module (com.shadowh511.mayor.inputs.DomBoard) that did all the work by itself. |
Re: What was the hardest to program this year in Java?
Some issues we had included:
1. Getting the cRIO not to throw random exceptions when using known working code (gotta love that cRIO imaging tool...) 2. Getting our drivetrain working (and not curving). We ended up scrapping RobotDrive and implementing our own Drivetrain class. 3. Making sure we didn't lose communication. |
Re: What was the hardest to program this year in Java?
Oh, and I forgot to mention: finding and fixing bugs in WPI's code. :p
So far we're overriding three of WPI's classes with our own versions: PWM, because someone forgot to cast two integers to doubles before dividing them; Encoder, because someone divided by 0.25 when they should have divided by four; and DriverStation, because the scaling on the joystick axes is wrong (it goes from -1.0 to 0.9 rather than -1.0 to 1.0 due to the use of two's complement). Not that I'm complaining; when volunteers write 20,000 lines of code there are bound to be a few errors. In fact, I'm glad WPILib isn't perfect, because then my programming team would have nothing to do after week one. :) |
Re: What was the hardest to program this year in Java?
It was actually student voulenteers
|
Re: What was the hardest to program this year in Java?
The hardest and most frustrating is debugging... But a lot of times, it ended up being electrical that was messed up... e.g. IR Sensor not lined up, Pressure sensor not wired up correctly, and ect
|
Re: What was the hardest to program this year in Java?
Was anyone else having a problem getting the debugger to work?
|
Re: What was the hardest to program this year in Java?
The hardest part of programming is always convincing everyone that it's not a code problem! Fine, it was twice, when someone accidentally would comment out `break;' on one-line cases in switches.
Things we did abstract farther: Our side kicker was incredibly complex. So, I created a the `hardware.SideKicker' class that made it work work like ``sideKicker.set(SideKicker.Mode.kLoad);''. It had 4 states: kick, load, close, and wait (which are normally run in that order). Beside that, I further broke the kicker down into the `hardware.sideKicker.Loader' and `hardware.sideKicker.Latch', both of which `hardware.SideKicker' used. Even after that, all the timing logic and such is still fairly complex, but I did manage to make it pretty zen. Same thing with the front kicker, although it is a lot more straight forward (kick and load), no timer issues other than the 2 second rules of the competition. We also further abstracted the driverstation ``LCD''.
|
Re: What was the hardest to program this year in Java?
to be honest, i stole my team's driverstationlcd class from the Comet's code
|
Re: What was the hardest to program this year in Java?
Hah, I think the most complex thing in my code was the kicker stepping system, though the order processing system wasn't all that simple either. Of course the autonomous handler and the stepping manipulator building-blocks system were way more complicated but those were disabled in the competition version of the code. This was simply because I had to finish them after shipping and the mentors didn't want untested code in competition. In regard to WPI crap, I ended up doing a bunch of extensions just so I would have my own inheritance tree to play with, and I had to fix some bugs along the way.
Oh and speaking of shifting the blame away from programming, I had some serious issues with that. For two days at our regional the robot didn't move on the field. It worked just fine in the pit, tethered and it worked fine at school on wireless. Eventually I solved the problem by reimaging the cRIO, but that was after the mentors had ordered me to remove the Java code I wrote and replace it with the default LabView code. (There was a lot of fighting about this. Apparently someone from another team that used Java but switched to LabView came over and said that the Java code was the problem.) Unfortunately, this whole mess has now prevented us from going to Atlanta, although we've already paid the fee... |
Re: What was the hardest to program this year in Java?
Quote:
As for the actual question, hands down our parallel kicker. It wasn't the code itself, but the implementation and lag prevention that was very difficult. |
Re: What was the hardest to program this year in Java?
i solved a similar lag problem with a kicker thread
|
| All times are GMT -5. The time now is 08:11 AM. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi