Team 973 Code Now Public

[zombiezen]

Team 973 presents our code from previous seasons. Notable is that 2011 & 2012 are entirely Lua, so teams interested in using Greyhound Lua will want to examine it.

https://bitbucket.org/zombiezen/team-973-public

[F22Rapture]

The choice of Lua is interesting -- what advantages and disadvantages does it afford you over Java/C++/Python?

[Mk.32]

I am a bit confused, how did you guys run Lua on our robots? And what advantages does it have compared to the usual Java/C++?

[inkspell4]

Would somebody please explain what luna is

[BigJ]

Originally Posted by inkspell4

Would somebody please explain what luna is

Lua is a scripting language (http://www.lua.org/). It is used a lot in the gaming industry as a second-level language to interact with higher level APIs. For example, World of Warcraft, Warhammer Online, and RIFT have all allowed users to create modifications to their user interface by writing Lua scripts against their exposed APIs.

I have never used Lua with FRC, but I am assuming the benefits are a faster change-upload-run cycle while developing code, because Lua is interpreted and not compiled.

[AdamHeard]

Originally Posted by F22Rapture

The choice of Lua is interesting -- what advantages and disadvantages does it afford you over Java/C++/Python?

Ross can provide more detailed answers on the technical side, but I'll field some of the reasons.

We're a small team, in a community that doesn't really prepare kids at all in technical fields. It's not uncommon for a student to have never used email before joining the team. It is rare we have any students coming in with programming experience, and more rare that we even have kids interested in programming (this last season and the upcoming season we have a few, which is a refreshing change of pace). Also, for random and unrelated reasons, we've had huge turnover in students interested in programming, 2013 will be the first season since 2008 that a student programmer participated the previous year.

Throw that all together with the fact that our mentorship is low, and it's HARD to get kids trained as programmers.

The barrier to entry with Lua is just lower than a language like C++. Students spend more time problem solving and doing the real tasks that programming is, and less time focusing on syntax and variable types. Ross is a computer science major (and I'm a minor in it), so we both understand the importance of these skills, but we believe they will learn these skills down the road in whatever college program they choose. We're more interested in just getting them to program (as programming in anything is better than not doing it at all), and letting them spend more time per hour coding on the high level tasks and logic problems.

It's worked well for us in that regard.

[Ginto8]

Originally Posted by AdamHeard

Ross can provide more detailed answers on the technical side, but I'll field some of the reasons.

...

I can help with some technical reasons as well:

As BigJ pointed out, Lua is used in a lot of games. The interesting thing about use in games is that games have very strict speed requirements. If a game is designed to run at 30 frames per second, everything has to run within 1/30 of a second (about 33 ms) or your game is going to lag. Games tend toward Lua because it's very light and very fast (some benchmark comparisons to python are available here), while still having the high-level advantages of a scripting language.

Even disregarding the speed or the general advantages of high-level interpreted languages vs lower-level compiled languages, Lua as a language is impressively flexible, with first-class functions and extensible tables allowing programmers capable of a little more abstract thinking to make some extremely clever code. It wouldn't necessarily be my first choice for FIRST programming, but I can definitely see why team 973 settled on it.

[zombiezen]

Originally Posted by Mk.32

I am a bit confused, how did you guys run Lua on our robots?

Greyhound Lua. It has been discussed before.

The gist is that the Lua interpreter is off-the-shelf code written in clean ANSI C. It compiles with minimal modification under WindRiver, and with some SWIG bindings to grant access to WPILib. It is released under an open source license and is free for other teams to use.

Originally Posted by F22Rapture

The choice of Lua is interesting -- what advantages and disadvantages does it afford you over Java/C++/Python?

All of what Adam said plus:

The edit/compile/run cycle is dramatically reduced, as BigJ pointed out, but even more than that, the barrier to experimentation is much lower. Students can try out snippets of code in an interactive interpreter and develop on practically any OS, since the Greyhound Lua interpreter only needs to be compiled once. We don't need to develop in WindRiver, so we have students that are using Ubuntu, Mac, Windows, vim, gedit, and Notepad++.

From a teaching perspective, the language of Lua also lends itself to procedural programming, which is easier to demonstrate and reason about for new students. Gone are the discussions of memory management, inheritance, and NULL pointer crashes. Lua instead builds from combining simple concepts. For instance, we can re-bind controls using closures inside a table.

I've been asked by people inside and outside FRC whether the use of Lua in FRC is a good idea. Their concerns vary from runtime performance to software engineering best practices (usually phrased as "Lua isn't a real language"). If I (as a mentor) were the only one writing the code, you can bet I would be using C++ because the syntax doesn't bother me and the static typing and performance help me during development. But it isn't about me; it's about the students. I've made sure to explain to the new students what the tradeoffs are and why the decision was made. Should all teams be using Lua? No, but it meets our needs, and ultimately, the choice of programming language in a software project does not matter. The real question is: "is your team productive?" And after the last two seasons, I think the results speak for themselves.

On a sidenote, the Python port didn't come until after I finished Greyhound Lua, and IIRC it uses the SWIG bindings I wrote. I initially tried porting Python, but found that the effort required exceeded the amount of time I had before the 2011 season started.

tl;dr: Lua fits our needs.

[Ether]

Originally Posted by Ginto8

(some benchmark comparisons to python are available here)

Why the big difference in CPU time for the pidigits benchmark?

[Ginto8]

Originally Posted by Ether

Why the big difference in CPU time for the pidigits benchmark?

Looking at the two programs, it seems that the python sample is using a built-in multi-precision library for python (GMPY, which includes C and C++ for speed), while the lua code is doing... something... with dynamic compilation to make it happen.

[apalrd]

Originally Posted by Ginto8

...games have very strict speed requirements...

Not to hijack the thread, but a 30hz (or even 60hz) timing requirement on a 2ghz+ x86 cpu with a 3d rendering coprocessor isn't really that bad.

Many automotive and industrial control systems operate at extremely high speeds, for various reasons. It's not uncommon for active suspension and other vehicle dynamics related systems to operate at 100hz to 1000hz, depending on how fast their actuators can be actuated, and these often run on relatively slow processors (e.g. I worked on a suspension system at 1000hz on a MPC5534 clocked at 80mhz, and many engine controllers I work with use the MPC5xx family at 56mhz).

[Ether]

Originally Posted by apalrd

Many automotive and industrial control systems operate at extremely high speeds, for various reasons. It's not uncommon for active suspension and other vehicle dynamics related systems to operate at 100hz to 1000hz, depending on how fast their actuators can be actuated, and these often run on relatively slow processors (e.g. I worked on a suspension system at 1000hz on a MPC5534 clocked at 80mhz, and many engine controllers I work with use the MPC5xx family at 56mhz).

The last embedded automotive project I worked had a 3000Hz task, a 1000Hz task, two slower tasks, and a handful of hardware interrupts (SPI, PWM input edge detection, etc) running on an 8-bit microcontroller clocked at 16MHz. I wrote the RTOS (preemptive with rate monotonic priority) and app (integrated) in assembly and C.

[virtuald]

Originally Posted by zombiezen

On a sidenote, the Python port didn't come until after I finished Greyhound Lua, and IIRC it uses the SWIG bindings I wrote.

Initially it used the SWIG bindings, now it uses SIP-based bindings.