Mindboards

Hi all,
I came upon pbLua the other day, and it sounds like a very good, high-level way of developing for the NXT. I'm not clear on how popular it is, because I'm just starting out, but I see that the language mostly mentioned here is NXC. Can someone explain to me the relative merits of each?

That having been said, I'm thinking of writing a small, open-source framework in Lua along with a small toolchain to easily upload/send scripts to the brick and execute them. Would there be interest in something like this, or does it already exist and I just haven't been able to find it?

The framework I have in mind would basically consist of an event loop, so that, instead of having to poll for buttons or sensors all the time, one could just define an onButtonPressed(button) method and have it get called whenever a button is pressed. The framework would also include some typical control functions such as hysteresis, Kalman filters, etc.

Is there interest for something like this or am I just duplicating someone else's efforts completely?

poromenos wrote:Hi all,
I came upon pbLua the other day, and it sounds like a very good, high-level way of developing for the NXT. I'm not clear on how popular it is, because I'm just starting out, but I see that the language mostly mentioned here is NXC. Can someone explain to me the relative merits of each?

I guess most of the folks who hang out here are interested in NXC because John Hansen (developer of NXC and Brixcc) is here. Some of the other contributors are working on other platforms (e.g., LeJOS (Java), RobotC, Matlab). My Interest is in Bare Metal (Assembly) programming, which makes me a minority

I had some contact with the author of pbLua previously during the NXTasy days (that was before Mindboards was setup). Disclaimer: I don't use Lua myself, I'm a C programmer, the only scripting language I tried to learn is Python.

Lua is a lightweight scripting language, that can be used in tight memory environments such as embedded systems. I suppose it really depends on your style of programming. Scripting languages make it easy to write incremental code and test it out without having to 'compile', but usually any syntax errors won't be caught until the interpreter tries to execute it (at least, that is the case for Python). NXC looks pretty much like normal C, so you need to write, compile, fix syntax errors, etc. before the code is downloaded to the NXT.

Lua requires its own firmware. NXC is basically 'C-lite' compiled to the NXT VM bytecodes, so you can run normal NXT-G programs as well as NXC programs with one firmware (John Hansen's Enhanced Firmware), as well as any program written to the NXTBINARY format which can be downloaded into Flash but runs only from RAM.

I see, thank you for illustrating the differences. I think it essentially boils down to the compiled vs interpreted debate, so each language is suited to its own use cases. pbLua does need its own firmware, which is a bit of a disadvantage, but I think that a small framework would find some use in the community. I'll have a go at it and put it up on github for anyone who wants to use it.

Thanks for your help!

poromenos wrote: I came upon pbLua the other day, and it sounds like a very good, high-level way of developing for the NXT. I'm not clear on how popular it is,

Not very popular I'm afraid, even though I bet it's a shame. It indeed seems like a good & nice high-level thing

poromenos wrote: That having been said, I'm thinking of writing a small, open-source framework in Lua along with a small toolchain to easily upload/send scripts to the brick and execute them. Would there be interest in something like this, or does it already exist and I just haven't been able to find it?

I guess it depends on how you promote it and on how well documented and stable it is. When we began developing the MATLAB toolbox, it was a total "niche" (can you say this), and maybe it still is -- there are not so many MATLAB users out there. Which makes sense, as it's commercial and very expensive. But because of steady work, some publications, and last not least the fact we force our students to use it , it came more and more popular (so that in academics, it feels like we're playing in the top league, at least university-wise).

What I'm saying: Do it well, document your intentions, keep on going, and this might be a really great thing. Just as nxt-python (forked from NXT_Python) is getting better and better. However, Python has a huge popularity bonus.

The bottom line is of course to "do something better" than others, or provide something that doesn't exist yet.

poromenos wrote: The framework I have in mind would basically consist of an event loop, so that, instead of having to poll for buttons or sensors all the time, one could just define an onButtonPressed(button) method and have it get called whenever a button is pressed.

Now that is something new and interesting! And since the NXT has limited CPU resources, it might be really useful... Or even a game changer ? Anyway, I like the idea.

poromenos wrote: The framework would also include some typical control functions such as hysteresis, Kalman filters, etc.

There's definitely a high interest in Kalman filters here, but it's got to be simple. So if you wrapped / implemented a nice working Kalman filter, configurable but with "sensible" default parameters, this would indeed be a great thing.

poromenos wrote:I think it essentially boils down to the compiled vs interpreted debate, so each language is suited to its own use cases.

Yep. Or the "on-brick" vs. "remote controlled" debate.
If you're interested in a rough overview about programming languages and techniques for the NXT, you can check page 43ff. of this free open book chapter: http://www.intechopen.com/articles/show ... -for-matla

poromenos wrote: pbLua does need its own firmware, which is a bit of a disadvantage

Yes, that's right. On the other hand, when you provide scripts / tools / GUIs to make this flashing as easy as possible, then that's a < 1 minute thing and hopefully won't keep people from doing it. And if you're really nice and you provide a script (and image) of the original firmware to restore it in a click (or a script that uses something like NeXTTool to backup the user files before flashing), then it will be even more likely for people to flash...

Btw, how is the motor control in the Lua firmware? Can you drive motors synchronized? Can you specify a motor target in degrees and reach it accurately? I know from personal experience and from testing LeJOS (and reading docs about it), that this is generally a huge deal and important to users. Or, the other way round: Bad motor control can be a deal-braker...

Thank you very much for your help, very interesting points! The remote-controlled vs on-brick debate is very apt, but I think nxt-python is too far off the brick and nxt-lua is too far on the brick. Maybe my framework will include libraries for easily offloading computation to the PC to execute and send the results back to the brick with bluetooth.

As for motor control, I'm not entirely sure, I've just started testing Mindstorms and pbLua out, even though I had them lying around for ages. On the pbLua site it says that you can, indeed, drive them synchronized, but I'm not sure of the accuracy of degrees. I guess we'll see soon enough!

Flashing is easy enough, as you say, I just had to select the file and send it to the brick, it took less than a minute and everything is working fine.

Thanks again!

poromenos wrote:Thank you very much for your help, very interesting points! Maybe my framework will include libraries for easily offloading computation to the PC to execute and send the results back to the brick with bluetooth.

Ah, the holy grail

Ah, the holy grail

Many brave men have come and gone before you:



Good luck!

- Xander

Yep! I don't see why a simple type of RPC couldn't be possible over Bluetooth...

Haha, I hope I make you proud, although I probably won't.

poromenos wrote:Yep! I don't see why a simple type of RPC couldn't be possible over Bluetooth...

If you plan to go this route, you should experiment with the message round-trip-time due to Bluetooth to see if it is acceptable for your application.
BT has some issues with switching latency of the channel between Tx and Rx on the NXT.

Sorry, I don't have more details, since I haven't looked into this, but there are others on Mindboards who have some experience in this area.