We have an issue on this site. No it’s not the 5 min theme job or the horrid content organization, it’s a much more fundamental issue. We just don’t have enough content to post. We could post about our wonderful executive meetings but those are obviously “top secret” (And involves a lot of faffing about).
While the team at UTS RoboSoc was contemplating ways of dealing with our amazing lack of content, we got a rather interesting email from some lovely people over at QUT (Queensland University of Technology).
They sent us information about a little competition they ran in 2016 called the Droid Racing Challenge and had sent us some details, asking us if we were interested in competing in the competition this year.
The RoboSoc team looked over the competition details they sent us (A summary of which is posted over here~ https://qutrobotics.club/2016/07/17/droid-racing-challenge-wrap-up/) and immediately realized that this would be a perfect project to attempt. Better yet, we could blog about the whole thing so everyone can watch as we struggle immensely doing something we’ve never done before.
So for the next couple months, we will be posting semi-regular updates as we build from nothing to, hopefully (desperately hopeful), a fully working racing droid that doesn’t crash into the first obstacle it meets.
Stage 1 – Spend Money, Get Nowhere Fast
Now, like all good aspiring engineers, there is certain procedures we must undertake the moment we decide on a new project. The most IMPORTANT of which is to use said project as a completely valid excuse to buy a whole bunch of new toys (a.ka. “work related content”).
After a bunch of research (10 mins on Google), a bunch of clicking, emptying paypal of everything we had and waiting in front of the post box to ensure that the bloody postman actually delivers the package rather than just leaving a collection note, we end up with this lovely bunch of parts below
Welcome, very expensive collection of parts
For people that don’t know what we bought, this is an Odroid XU4 Single Board Computer made by a company called HardKernel based in South Korea. It is an alternative to the much more popular and widely used Raspberry Pi lineup of single board computers, except with a few differences.
One of the biggest differences and the chief reason we picked this board was “performance.” This thing will absolutely hammer a standard Raspberry Pi in most workloads, courtesy of a much more powerful Samsung Exynos 5422 SOC (The brains of the unit) with 8 ARM CPU cores and a much more powerful GPU. How much more powerful?
As this lovely graph from HardKernel demonstrates, a lot more powerful. This is clearly assuming we trust HardKernel’s marketing department but that is something we can test for ourselves later.
As for why we need all this performance, as part of this project we are going to be running a lot of Computer Vision related algorithms through OpenCV. The faster we can process through all our sensor and vision data, the faster we can drive our vehicle. The faster we can drive our vehicle, the closer we get to victory (and the more damage we can do once it inevitable crashes).
People who have read the QUT post before reading this would already know that most teams last year used Raspberry Pi of some description. If the Odroid XU4 is clearly better, then why was it not more widely used? Well…..
There is ALWAYS a reason
I could spend another couple hundred lines boring you with the fine details of everything that went wrong so far in the short couple days we had the board but for the sake of everyone’s sanity, lets just list them as bullet points
- Provided power supply is seriously questionable. 5V/4A with a dinky little wall wart might as well be a bonfire starter
- Optional touchscreen has viewing angles that work best after you get a protractor out and make sure your eyes are at 0 degrees to the screen. On the plus side, it’s an awesome security screen so no one else could possibly make out what is happening on the screen besides the user with the amazingly stable eyes
- OpenCV (A key part of the whole project) won’t actually build if you’re using the latest version (3.2.0). Need to use an older version that works (Version 2.9.4 works and supposedly Version 3.0.0 should as well)
- No built in wifi or bluetooth
- There is some custom images to make life easier but a lot of them haven’t been updated in a while
- The community in general is MUCH smaller than the RPI community
The most annoying issue out of all these is definitely the software ones. We initially tried to load some custom images from the Odroid forums just to test things out. On a RPI this would be fairly easy, you download the image, image it using WIN32DiskImager, plug the SD card into the RPI and it works.
On the Odroid, you download the image, image it onto the SD card, mess around with the boot settings if you’re using the touchscreen since no image supports the bloody thing stock, plug it into the Odroid then spend many hours wondering why it keeps entering into a kernel panic and refusing to boot. Tried at least two custom images before just giving up and loading the default Ubuntu.
Thankfully THAT works after a bit of messing around with the VNC clients and auto login. Then we ran into the whole problem with OpenCV not building.
Suffice to say, it’s definitely not as user friendly as the Raspberry Pi is. Hopefully the performance difference makes up for it once everything actually runs on it. As we write this blog, the Odroid is still trying to build OpenCV 3.0. Thankfully it hasn’t stopped yet with an error so we’ll take that as a positive sign.
The next time we write a blog post, hopefully the whole thing is up and running so we can talk about actual robot stuff rather than a massive long rant. If it doesn’t work by then? Well… we’ll just take the obvious solution….