Learning to Program – Part 2

In a previous post, we described a process that we hoped to undertake in order to get more of our students writing an auto. Over the early part of December, we saw of some of these plans come to fruition, and saw some of the first autos from our our students.

We had around 10 students participate in CodeWars. They found it to be a considerable step up from Code Academy, however, it did seem to be beneficial and brought out a set of students who had at least some familiarity with basic programming constructs.

We started with our setup of Visual Studio Code. It progressed without too many glitches. A couple items that we noted were that it required the OpenJDK and wouldn’t operate with the JDKs we already had installed (Oracle). Additionally, by default the OpenJDK installer doesn’t set the JAVA_HOME path. (The installer does have an option for this though). We found that the install could be completed in under 5 minutes by someone who was familiar with it, but took about 30-45 min for students going through it for the first time.

Once we got the environment setup, we created an a new IterativeRobot project and began to initialize our motors, joysticks, and drive classes. We looked up the motor IDs (in the NI Dashboard) – the Silverlight requirement proved to be a bit of a challenge, so we are definitely looking forward to the possible changes to the dashboard in 2019.

It took about 2 hours for our first run through a simple ArcadeDrive teleop. This included determining the basic steps that would be required, looking up methods in the APIs, finding the IDs needed, and debugging the syntax errors. By the end though, every student who had come out for the day (most with no prior programming experience), had managed to write their first teleop, push it to one of our robots, and test it out.

From here, we attempted to extend our robot code to include a simple drive straight auto. For simplicity, we approached this with just a simple counter. We set the wheels moving in autonomousInit, incremented a counter in autonomousPeriodic, and stopped the wheels once we crossed a certain count. The one item to be aware of here is that there is a watchdog timer that ensures a signal is being received. If the watchdog isn’t ‘fed’ every 100ms, the motor will be disabled. As such, autonomousPeriodic requires calls to maintain the speed and not just to stop.

We found it considerably easier to write a simple drive straight auto than to write the initial teleop code. This is likely because the auto code was much more traditional programming (an iterator and if-statement) as opposed to the initializations which were all referencing unfamiliar classes. After a few tries, all the students were able to get a drive straight auto written. For this first day, we tested it on a robot that was on blocks (as opposed to on our practice field).

A few days later, we moved our robot to the practice field and had a go at making it actually move. This progressed well – the code that was working on blocks worked well on the field. We found a couple of scenarios where not all the motors were initialized (resulting in noticeably slower performance), but these were all resolved by the end of the evening.

One significant addition on our second day was rewriting our drive straight auto to use encoders instead of just counting. This proved to be quite simple and students began to get accustomed to writing code after seeing the constructors from the API. The encoder based auto worked, going the desired distance quite easily.

Our next task will be actually going straight. Unfortunately, the robot we were testing on pulled significantly to one side. Our next iteration will include a PID controller using the gyroscope read and maintain a constant heading.