Sunday, December 31, 2017

I’ve attached a 32 x 32 grid that you can use to design icons for our new VI’s. Be creative, and come up with a good theme that can be carried through all of our custom code this year.

In other news, there is yet another release of the CTRE drivers (v. 5.0.9.0). The FIRST beta test has run out of it’s forum software licensing, so it may be unlikely to contribute more to the process. At this point, we have made positive contributions to the beta in improvements and changes to software that will benefit every team. From here out, we will have to be more public on Chief Delphi and other FIRST-specific online communities. We are in a good position to do this.-- Len

Sunday, December 24, 2017

I sent out the Python codes for challenge 7 a little over a week ago. Well, I only got one attempt to improve code, but it was a good one!

Greg honed his code, and it is now a full second faster than my code (when run on the same hardware/environment). This is now what the performance chart looks like:

When asked what made his so much better, Greg responded:

"The thing that made my code twice as fast was not trying any even numbers because even numbers divided by 2 will result in another even number until it reaches 1. For example 8 dived by 2 is 4 that divided by 2 is 2 and 2 dived by 2 is 1.

another thing that significantly sped up my program was using integer division rather than floating point division. Integer division also known as floor division returns an integer rather than a float so the program has to do less work divining floating point numbers and it therefor goes faster. "

I’m going to hold off on the next challenge until after we complete the various VI’s that will be needed for our custom holonomic drive.

The 2018 beta period has not technically finished up yet, and we still have some work to finish before the end of calendar 2017. For everyone new to how FIRST treats team-written software, you cannot use any code that was made prior to the new game kickoff, unless it has very publicly released to every other team. We would like to use what we discovered in the beta, and the best way to do this is to make new code that other teams can use.

The big discovery we had is that CTRE’s massive re-write of all of their software has MAJOR repercussions for all teams like ours that use encoders and closed-loop feedback. This is a huge problem for the holonomic drives that we have been using, and are currently building to write new white papers for public release.

I would like to have a new custom Holonomic drive VI, ready to release to everyone by December 31, 2017. This will allow us to use this new code for everything. The following is what I am proposing:

For now, this new custom holonomic code will only work as a robot-specific drive (not looking at field centric at this time). The additions, when compared to the WPI holonomic are the mode switch, which can deal with closed-loop speed mode. Unfortunately, WPI won’t work like this now, so this is the major reason for this code.

The other big difference is the bottom left bubble, “Drive Configuration”. This is essentially a way for us to specify what the drive is with each wheel getting a perpendicular axis, wheel type (omni or mecanum), and wheel size. This would give us a hybrid holonomic for dummies configuration. One other thing to notice is that the drive configuration will define the number of driven wheels, and the address for each. This gives us flexible n-way holonomic drive. 3, 4, 5, 6 or more motors can be configured and driven.

Internally, the functions break down like this:

There are more sub-VI’s that will be necessary. I just wanted to give the next-level-down conceptual version of what we need to do. If there is a part that you want to work on, let me know. We can break a bunch of these down into much simpler chunks that are more approachable. We have a week to make this work.

Thursday, December 14, 2017

Tonight I am sharing the results for the Python entries for the coding challenge. I have not had time to go through them to write a critique on what each one does well or needs to improve on. Instead, I’d like to see two different things happen.

First, look at the code. See if you can identify the things that make any of the programs run faster or slower than the other codes. There is a reason why the fastest code ran almost two and a half times faster than the second fastest, and the second fastest 20% faster than the third. Why?

The second thing I’d like to see, is if you can take any of these and make them run faster than the current fastest code. As we saw last week, we had a program that ran and got the answer in three hours and fifteen minutes, but with a few minor tweaks, it ran in just over five-seconds and got the same correct result. Optimizing your code is like getting a massive upgrade for your computer. It is an essential skill that we all need.

Without further delay, here’s the comparison of running times for all of the Python programs:

Sunday, December 10, 2017

I know that many of you are working on the Collatz series programming challenge. I know of two that are in progress, and a third that has been submitted. There is just over two hours to get an entry in.

Even if you don’t get a completed program done, submit what you have. The one entry that I have gotten so far has gotten the correct answer (but not the correct count).

There is a lot of computation in this problem. If your program is taking more than ~5 minutes, you probably have a bug where you aren’t hitting an end condition for one of your loops. Use a print() statement to help debug what is or is not working.

Wednesday, November 22, 2017

As always, I encourage everyone in the programming group to look at and code an entry for our existing contests. Right now, however, I am giving a new one that isn’t posted on the programming challenge page of our website.

So without further delay, here is the contest problem:

The sum of the primes below 10 is 2 + 3 + 5 + 7 = 17.

Find the sum of all the primes below one million.

As with the other contests, you can submit an entry using LabVIEW, Python, or both. Evaluation will be on accuracy, speed, and code documentation (comments).

I don’t like to give hints upfront, but if you look at the existing contests, there is one that deals with prime numbers, that may be helpful. Further, the commentary surrounding the prior contest solutions may be just as important as the actual code, in gaining insight.

We had a very productive afternoon meeting last Friday! We were able to get the following done:

Shake out Moldy’s wiring. We corrected three different wiring faults.

Test the flashing of the robot radio with the newly released beta firmware.

Test a new release of the roboRIO flashing utility that included specific changes that we requested (we are making a difference for every team!

Tested migrating our existing 2017 code to the new system. There is still pain here, but we found new pain points.

Unfortunately, #4 kept us from actually getting Moldy to a running state. We had hoped for a release of new libraries to fix that problem by last Friday, but that software has not arrived yet.

Speaking of software, I now have version 2.0 of our Python / OpenCV VM and the FIRST Beta software hosted on our server, with no public links. These links will get you the entire new stack of our software.

Python / OpenCV

Download VirtualBox at Virtualbox.org to get the latest version and the extension image.

Unzip and install the FIRST update. We are now on the third update of this software. It uses the same serial number.

Those parts are all you need to get started with learning LabVIEW. To work with team code, we need more…

Unzip and install the CTRE software. We cannot successfully port our code to this version, but the next version promises to fix our issue.

Unzip and install the NavX software. This version is from last year. It should work, or at least put the software somewhere near where it needs to be to work.

The new version of our VM makes some significant changes, so I suggest that you delete any of the version 1.x VM’s you may have installed. This version is significantly smaller in overall size (4.5 GB vs. 10.1 GB). It is based on Ubuntu 16.04 instead of Ubuntu 14.04, and the Python virtual environment uses Python 3.5 instead of 2.7.

As before, the LabVIEW software requires installation on a Windows machine (real or virtual).

Now that you have access to software that you can download and install while waiting for a turkey to cook, watch for my next post, which will be for a contest over break.

Saturday, October 28, 2017

FIRST has made public the list of teams doing the Beta Program, and plotted them on a map. We are one of only two teams west of Texas, in the LabVIEW Beta. There are four other teams in California in the program, and all of them are doing C++. Almost all of the beta teams are in the US. The only team in Europe, Africa, or Asia, is in Israel, and they are using LabVIEW. There is one team in Australia, and they are using C++. In the picture, LabVIEW is blue, C++ is red, and Java is yellow.

Nidec Dynamo BLDC Motor with ControllerThe new brushless motor/controller combo that a small number of Beta teams will be testing is the Nidec Dynamo BLDC Motor with Controller. This small 12V DC Brushless motor/controller will be legal for the 2018 FIRST POWER UP Season, and will be available in FIRST Choice with additional units being sold by AndyMark.We feel that this low power, integrated motor/controller combo is a great way to introduce brushless technology to FRC and are excited to have Nidec working to bring it to teams this season. Nidec has been working with FIRST to provide a custom cable harness with the motor to make the connection between the controller and the roboRIO as simple for teams as possible. We can’t wait to see what teams will do with this new technology this season!Note: Teams will need the 2018 FIRST Robotics Competition software to control this motor correctly, so you will have to wait until Kickoff (and pay close attention to the documentation!) to start playing around with it. Until then, check out the datasheet here for more details about the electrical and mechanical specs.Note 2: Are you unsure about brushless motors? No problem! Since its inception, FIRST Robotics Competition has allowed only brushed motors. However, brushless motors are widely used in many industries! For more information about the difference between the two, check out this link.

Which is really cool and exciting! This is the first time a brushless motor has been used in FRC and we are hoping to be one of the Beta teams to test that technology. While we are waiting to find out if we are, click the links and brush up (hahahahahah) on the technology, because this is a very real option for our 2018 robot and we want to be able to have informed discussions when discussing motor choices in design meetings.

Today is the Quarter Auction fundraiser for our Junior Robotics program. I hope to see some of you there!

Wednesday, October 25, 2017

Sorry for the late notice, but we won’t be holding the Thursday offsite meeting this week. Please spread the word to others, as not everyone is plugged in to their e-mail.

That doesn’t mean that there is nothing to do. I hope that you have been able to poke at 2018 FRC LabVIEW to get more familiar with it. As I mentioned before, you can learn how to use it better by re-doing some of the programs from the programming challenges.

One of the problems we had with the beta software was missing VI’s for the Talons and the NavX. CTRE has released a new version of their installer package (v. 5.0.4.2) that should install the VI’s in the correct place. There may still be issues due to renaming, but at least the VI’s should now be findable. Kaui Labs has not released a version of their software through the beta program, so their VI’s will have to be installed from their publicly available package.

Wednesday, September 27, 2017

We won't be holding a Thursday off-site meeting for programming this week. Instead, we will be having a LabVIEW party at the robotics room on Saturday from 9:00-2:00. Bring your laptop if you have one, as a limited number of team laptops will be available.

Congratulations Team!

We have been selected to participate in the 2018 Beta Testing program for FIRST! This is a huge honor and responsibility, as there are only 30 teams globally who were selected for each language, and many of those spots are being held by long-time Championship-level teams that have been beta teams for several years. We are specifically assigned to test the new version of LabVIEW and the respective FIRST code libraries.

So what does this entail for us? We will be thoroughly testing the 2018 software and potentially new hardware ahead of most teams. We have to document what we’ve learned. We need to give feedback to FIRST and their suppliers. We need to share what we’ve learned and become an authoritative contact for other teams. Like I said above, this is a huge responsibility.

This will take the efforts of the entire team, as we will have to get both Toasty and Moldy back into competition shape. Specific to the process that FIRST uses, I need to collect 9 other official participants (students and mentors), as soon as possible. If you are interested, just post below or send me an e-mail indicating your interest.

Wednesday, September 6, 2017

First of all, welcome to all of the new members who expressed interest in programming, coding, or “anything” at today’s meeting. I’m sorry that I wasn’t there to meet you, but I’ll get to know you soon enough.

If you haven’t visited the team website yet, you should get into the habit of checking it out at here. The Buzz page is automatically updated with stuff from the team’s various social media feeds. Very soon, we will be updating the main site with more recent content and adding a programming blog. This will be a persistent place for much of the information that I send out over e-mails, and a place to have discussions over different coding topics. The site also has a calendar under the Team Resources area that should be the most up-to-date scheduling for meetings. Our items will be deep red in color, but you should also check out other events (especially the pink ones).

For those of you new since last week, we use two different languages or environments for programming our robots. We use LabVIEW, a graphical-based language for main robot control and the off-field dashboard. We use Python with OpenCV to do our vision programming. I now have the VirtualBox VM ready for Python programming with OpenCV, which mimics the system used on our vision processing computer. This can be installed on your own computer, so that you can get up to speed as fast as possible.

To spread the love, we will have a VirtualBox install party at the Evansic house tomorrow (Thursday) night. It is the next red block on the team calendar. Bring your laptop (Mac, Windows, or Linux), and you too can get your own tools to play with and learn Python and OpenCV!

If you can’t make it (I know, short notice), the VM and other related information will be available when the website is updated.

Wednesday, August 30, 2017

One of the big questions that I get about coding for the team is why "Python and LabVIEW?” We could use Java or C++ instead.

The simple answer is the same for both languages. LabVIEW and Python are easy to learn.

When Mrs. E. and I came to the team in the 2008-9 school year, FIRST FRC was transitioning to an entirely new control system from National Instruments. From the beginning, it could be programmed in C++, Java, or LabVIEW. The previous controller used a derivative of C, so it was decided that we would use C++ to program the new system. It seemed that this would be the best fit.

Four weeks into the build season, our team programmer had spent a LOT of time trying to get the C++ framework to work. At that point, I was a bit worried that we wouldn’t have any working code ready for the robot. I sat one of the underutilized team members down at a computer, and in two hours, we were able to replicate everything in LabVIEW that the main programmer had struggled to get working in C++ over four weeks. On top of that, we even made a working vision system for that year’s game that could discern different colored balls.

Now, please understand, our main programmer was and is a very smart guy. He eventually got all of the code working in C++, but it took a huge investment on his part. Nobody else on the team had any hope of understanding how the code worked, as nobody had the time that he had spent on the code. LabVIEW was and is much easier to get up to speed with. We have mentors that know LabVIEW and we get sponsorship money from National Instruments for using it.

Our use of Python is a little more complex. We use it on the nVidia Jetson platform, which is an ARM architecture with a lot of GPU cores. We could use C++ on this, as OpenCV (the computer vision library we use) is written in C++. Why don’t we use C++ here instead?

As mentioned before, Python is easy to learn, but that isn’t the whole story. Python is Python is Python (within the same version). If you run it on Linux, Windows, or macOS, it works the same. C++ is NOT the same on those three platforms, as the compilers for C++ are different on each. Linux uses g++, macOS uses Xcode (llvm Clang underneath), and Windows uses Visual C++. They all compile C++ code, but do it very differently, and to varying levels of adherence to ANSI standards. This means that C++ code written on one operating system is not guaranteed to work on another without a lot of testing and re-writing.

Last year, we did encounter differences in how OpenCV that was called from Python behaved on different platforms. This was primarily due to the use of different compilers on different systems. The Python code we wrote, however, behaved the same on Windows, Linux, and macOS. As mentioned in the last e-mail, I am working on a virtual machine solution that we can all use to replicate running on the Jetson. We might be able to use C++ in this virtual machine, as the compiler will be the same as what the Jetson uses, although the underlying CPU’s will be different.

Perhaps the best reason I have found for using Python for vision is a site that is dedicated to using OpenCV with Python. Please visit PyImagesearch.com for the best guides I have found for learning computer vision topics. Adrian’s blog entries are way better than the books that I had found last year. He really does a good job in breaking things down to be much more understandable. He also covers topics that are extremely advanced (like machine learning).

I just realized that I didn’t address Java. Well, I don’t want to make anyone suffer that much. I’m told that Java 8 is not as bad, but bad is relative, and it is still Java. In all seriousness, Java is a third-class citizen for robot programming. The FRC Java framework is a wrapper on the C++ framework. The C++ framework is itself a second-class citizen, as it usually trails the LabVIEW framework when new features are introduced or bugs are fixed.

If you want to use Java or C++ (or Swift, or C#, etc) for a project, just reply privately and let me know. All computer languages are just tools, and one of them may be a better tool for something that we do. The more tools you have, the heavier your toolbox will be.

Tuesday, August 29, 2017

It was good to see some returning members and meet some new members at the Junior Robotics Kickoff meeting on Monday. We have a lot of new challenges ahead of us this fall, so I’d like to get a strong start to this semester.

Many of you know that we currently use two different languages or environments for programming the big robot. We use Python with OpenCV to code our vision system on the nVidia Jetson platform, and we use LabVIEW for the main robot and dashboard programming. This fall, we will also be investigating several different ways of programming an Android based controller for our First Tech Challenge (FTC) team. None of the FTC options are Python or LabVIEW, so it will be a great opportunity to learn something new.

This summer, we posted some mild programming challenges on the team website. The primary goal of the challenges was to develop problem-solving skills. Problem solving is what is really underneath all programming and engineering. The secondary goal was to get more exposure to working with either LabVIEW or Python. I encourage all new and existing team members to look at, and attempt these challenges, as it will really help in learning programming languages that may be new to you.

The lowest-cost of entry option for the programming contests is using Python, as it is free and works on Windows, macOS, and Linux. If your computer doesn’t already have it installed (this is mostly a Windows problem), you can download the appropriate package from http://python.org. We are currently using version 2.7.x.

I am putting together a virtual machine image for vision programming. This image will closely replicate the working environment on the Jetson, so that more work can be done without having to physically have access to the Jetson hardware. More details will be shared on Thursday night. If you want to get a head start, you can download and install Oracle’s VirtualBox software (free), which is available for Windows and macOS. It is available at https://www.virtualbox.org. I anticipate that the virtual machine image will take around 10 GB of space, when it is completed.