After much thought, I think the best way to “control” the robot’s artificial intelligence is by using a “script”. If you are familiar with games, the game is usually not hard coded into the source code, just the engine. So the game developers usually use a scripting language like LUA to code the game. I was thinking that implementing LUA to the cRio is possible. I see no reason why it would not work. If you are unaware of LUA, its a scripting language that is widely used in the game development communities. Any ideas why it would not be a good idea to use LUA as a mean of programming the AI?
-
I would rather take Python because, well, i like it more then Lua.
-
You are cross-compiling a library designed for platforms other than VxWorks for VxWorks. They are not designed to work together, and although they will probably work, it won’t be just as simple as cross-compiling Python to a .out file.
-
You probably have no idea how complex the Lua/Python interface is. It’s not like you are literally calling a function in another language, and it calls you back. You are passing variables through to the other side, pulling from, and executing script. You are also registering callback functions, etc, and an interface is not a trivial thing to write.
-
Lua is not limited to game development, neither is Python. For example, Blender uses Python for import/export and other scripts.
-
What do you gain as opposed to writing “scripts” in C? C is procedural, can talk to C++, and, well, is a lot less work then Python or Lua. You are not attempting to modify a common low-level engine to be re-used, you know exactly what you want to do and thus don’t need to extend the power past compiled code.
-
I have no idea how the cRio would take the giant amount of sensor and motor data flowing through the Python interpreter at 20hz, plus the execution of the script. You may have the problem that Java used to suffer, where it was quite slow because it was interpreted bytecode. I assume it would not like it at all.
-
In my experience with Source engine, many things are actually coded into two DLL’s that run the game. Some games/mods use Lua and Python for extensibility, like addon functionality, but that is not really necessary here.
-
Would consider
-
LOL Look at me trying to tackle full automation, can you tell me that I will easily change my mind?
-
that is true, but I was already considering on using an onboard computer to do the logic and imaging
Any better alternates than scripting languages? I can not think of anything may be other than a Config file that just states what prewritten behaviours to follow
Why not “script” in the native language, C/C++?
You could run the code procedurally, call functions that do stuff, sequence them, etc. and run them in their own threads.
I don’t see why not. After all, someone’s already ported a JavaScript interpreter to the Java environment.
Scripting languages really have become a science, with so many available. Take the JVM, for instance: languages from PHP to Python to Ruby (even lua) all have Java implementations that can be embedded in code extremely easily, and perform quite well. Some (ie, JRuby) have outperformed their C/C++ counterparts.
As for Lua, though, a quick google search revealed a J2ME-compatible Lua interpreter that could probably run on the current Java environment without too much trouble.
I am working on porting a LOLCODE scripting engine for use in autonomous
To the original poster,
A so-called scripting language is really just another layer of abstraction between the user and the robot.
Why would you want to take a robot that could be programmed in C and C++, two of the most widely-known programming languages there are, and add another layer of complexity along with the potential of another set of errors?
You can do the exact same thing in C in the way it was given to you with call-able subroutines, procedures, and classes that make it easy to program autonomous.
In fact, that’s a large part of what has already been done for you with the different libraries provided.
Then, not only do people have an environment to work in that they are familiar with, they can go and look at the C-code and modify it directly, without all the extra headaches that go along with an un-needed additional layer of code.
What benefit is gained by using an additional langauge and layer of complexity that cannot already be gained by clean and concise C programming?
My input would be to focus on the core libs. You can start with simple C/C++ code to sequence through core routines and test the initial autonomous.
Once you have that under your belt, you want a way to safely and quickly write alternative auto routines. If you don’t want much flexibility, you simply make it data driven using XML or another text format, or even Excel or other spreadsheet. If you want to be able to loop and make decisions, these lack enough flexibility, so you pull in a safe high-level language.
If you don’t get the core stuff done, you’ll find yourself writing too much code in the scripting language, which will hurt the performance and will turn difficult since scripting languages typically run into issues doing low level stuff.
Greg McKaskle
Exactly.
In fact, if you want easily changed code, it’s easy enough to read waypoints or other direction and distance data from a text file on execution of the code. Then changing behavior is as simple as modifying a text file of waypoints or something to that effect.
The basic need for scripting in a large integrated system comes from the need to reload non-core files without having to reboot due to relatively long reboot times (even 30 seconds is too long in some cases). Configurations are typically done in xml or some othe proprietary format, whereas procedures are typically done with shell scripts. It also allows for an adhoc content management setup so that a single link points to the current script file to use when there are multiple options/versions available. Changing the link (manually or automatically via code) changes which script a procedure points to. The nifty thing about this is that it allows for bug fixes post-deployment, yet remember we’re talking about large software systems here…systems that may run on the stock market, large multi-manned vehicles, satellites, etc.
An architecture for a robot is easily extracted from this setup, yet there must be a core process that runs and calls the scripts continuously. Race conditions must be accounted for, as well as file I/O issues such as stale handles to files that were deleted/replaced.
It seems trivial and easy, yet the reality is that scripting in such a way will cost more overhead that it’s worth for most typical robots. You would need an engine to handle the scripting, file I/O, and robot control all at once. While I agree that a gaming engine is the closest neighbor to that requirement, a typical robot processor (particularly an isolated, remote autonomous robot) does not have the juice or power longevity to support it. FRC robots may have the processing power to handle it, but do not nearly have the necessity for it given all of the matured development tools.
There are about 4 more posts that discuss this in greater detail but this was the easiest to quote.
In 2007 I was working with team 1493. We had two programmers, I focused on the autonomous code, and the other programmer focused on the tele-op. I developed code for the first 4 weeks, before we got a Chassis to program, in the manner described by other posters. To the extent where some one with no knowledge of C could read our autonomous mode and tell exactly what it did, more importantly some one with no knowledge of how the underlying control algorithms worked, could, with little to no direction write autonomous modes. The 5th week I tuned all of the control loops.
That weekend (between the 5th and 6th weeks) my mother passed away, I had to go home, and for a while robotics was at the bottom of my priorities. However because of the way I wrote the code, our other programmer, as well as non programming control team members were able to script the autonomous routines. When I got to the regional all that I had to do was fine tune control loops.
I highly recommend developing in this manner.
First, I’m glad I’m not the only one with this bad idea.
Second, has nobody thought of the simple reason “to learn”? Isn’t that a huge part of robotics? Learning? Even if it’s slow, you can still learn a lot by doing it.
Try asking that to the developers of Python, Ruby, MATLAB, PHP, Tcl, Perl, JavaScript, and Lisp. Why? Because its faster and easier to develop code in a scripting language. I would love to ssh into the robot, open a python shell, and start hacking away. I don’t have to recompile and download my code each time, I don’t have to mess around with a C/C++ debugger, and I can even experiment with things interactively.
Don’t get me wrong, I like C/C++, and Java too. I grew up with them, programmed more than a few robots with them, and learned a ton. I’m using both in my current job. GDB and other debugging tools are great, but they can’t beat MATLAB for ease of debugging. There’s something about the ease of scripting languages that makes programming fun. Controlling a LEGO Mindstorms robot with Python is a blast; I can only imagine the fun we could have in FRC.
All that said, I’m not sure if the CRIO is ripe for scripting. The thing that makes Python (and PHP and MATLAB) so easy is that there are tons of libraries available only an command away. A language written from scratch wouldn’t have the power that these do. Porting an existing interpreter is an even larger amount of work, and for the near term, using C/C++ is a lot easier. As others have said, it’s possible to write a good code base so that the C++ you have to work with is more like scripting.
Let’s all remember that there are some tasks well suited to opening “a Python shell, and start hacking away.”, and there are others which absolutely are not.
Getting an FRC robot onto Einstein might be one that is, or it might not.
Don’t get me wrong - I do plenty of hacking. Saying that hacking is bad is not my point.
Here is what I suggest you focus on: A good programmer will know how to succeed at both styles of coding, and will be wise enough to know the differences between them, and to know when each is appropriate/useful.
Students - Learn enough about both styles, and be comfortable in either.
An FRC robot can be a useful place to learn about either approach. Both approaches have advantages; and it is a sign of wisdom to be able to see past slogans and superficial differences when talking about either.
Blake
PS: So - What is a time when hacking away in a scripting language, is absolutely not the right approach? How about when my life is on the line in an airplane that uses the resulting code. What about in an FRC robot? Maybe. Assess and balance the risks and the rewards.
Another example would be automotive smart actuators, but for a different reason: with the high volumes, pennies matter. Coaxing the required performance out of an inexpensive microcontroller often means you can’t even afford the overhead of a commercial RTOS, let alone an interpreter. Coding for such an environment requires a unique set of skills.
This applies to nearly any consumer electronic device. I can tell you for a fact that there are almost no mass produced toys that are coded in a scripting language.
TomLine has had the best set of comments about scripting. In my world I program at five different levels:
Bare metal - This is low level microprocessor code, it’s running on the processor there is no OS involved. I program in C so the steps are compile, download, test. But I have a PIC development environment so I can also do some interactive debugging on my desk before I download code to the hardware.
Robot code on the cRio - Low level code, while there is a kernel OS running, the system needs to be restarted to test. So the code cycle is the same as bare metal
Code on an OS that needs to be restarted - Java and C where the application needs to be stopped and restarted. There is a huge selection of tools that can be used to develop with interactive debuggers to make the development process much faster
Code on an OS that does not need to be restarted - The land of scripts. There is a interpreter process that runs all the time processing the script. When there is new production code the interpreter process is directed to the new script and it runs that. I program mostly in TCL for that environment.
Programs that do X out of the box, but I need to extend the functions. In most cases the company has allowed me to call some “scripting language” from points in their product. For example the proxy server I use allows me to call Lua code to do specific processing of a message. The short fragments allow me to have custom code without rewriting the entire product.
Some of the “faster in scripts” has to do with the functions built into the scripting language or libraries, not with the code. Perl and TCL have some great array and string functions built in so there is less code to write. But there are great Java and C libraries that you can use so the code effort is almost the same.
The key difference in my world is that we use a structured methodology to programming. Analysis, design, code, test, implement. Half the time in analysis and design, 1/4 in code, 1/3 in test. Always the same, C, Java, TCL, Lua. Now there are mentions to “hacking away”, just jumping in and cutting code. And those people will take more time because they are not doing the analysis and design up front, they do it and re do it as they go. So there is a good deal of rework as they go along.
But because it’s ongoing code, test, code, test, they don’t see the embedded analysis and design time. (And I’m a big fan of agile methods (I’m a certified Scrum master) but there is analysis and design going on)
Blake makes a good point about “hacking away” and safety. Not on his plane, maybe on the robot if he’s out of the way. Nothing to do with the “language” in use. I can write equally good code in C or TCL, the testing process is what makes the difference.
Greg McKaskle makes a good point to start with the core C calls. If I was going to do your project I would pick a scripting language that can be embedded in a C program (like TCL) or Java (like Lua). I’d build the core infrastructure (API calls) that runs the motors and IO ports and let them be called by the scripting language. Make a way to stop and restart the core program externally so the script can be changed.
My big points are:
- Planned code development isn’t that much different from language to language.
- Ad hoc development (hacking) is fine if you don’t need to depend on the results.
- Scripting is attractive to our robot worlds IF it would end the long compile / reboot cycles.
- There is no silver bullet. (The Lone Ranger is an actor with a mask)
Keep us posted on how your scripting kernel works out.
Same here. I’d be interested to hear if anything comes of this.
Integrating a scripting language is not a bad idea, depending on usage.
If you are trying to do a lot of programming that you don’t modify much, then scripting is NOT the answer. You can write an interface that acts like a scripting language in C/C++ and compile it.
However…
Autonomous is often modified, so scripting autonomous may be a good idea. I think that the best way would be to create an XML definition for waypoints which the robot will navigate between on its own. You could then use a high-level scripting language to evaluate expressions, such as speed. Example: You are playing Overdrive and must knock down the trackball (or two) of your color. However, you want to slow down until the mechanism to knock it down is ready.
<waypoint x=35 y=8>
<curve>0</curve>
<elev_state>knock</elev_state>
<speed>14</speed>
</waypoint>
This assumes you want to go 14 ft/sec. With scripting, you could also do:
<waypoint x=35 y=8>
<curve>0</curve>
<elev_state>knock</elev_state>
<speed script=1>= 14 - ( (35 - nav_d__remain) * elev_error * .1 )</speed>
</waypoint>
Then the robot could evaluate the script to find the desired speed, based on how far the elevator is off and how far the nav distance remains to the target. This would allow it to slow down less when it has more time to get there. The waypoint also has a flag to set the elevator state to “knock”.
Using a scripting language in this case would allow the programmer to modify autonomous variables quickly and save the .xml file to the filesystem, eliminating the need for compiling, downloading, and rebooting to make small auto changes.
HOWEVER - you might not need this. A simple XML parser will probably provide everything you need. It all depends on the game.
PS. If anyone does write a Python or other scripting language interpreter interface for LabVIEW, I want a copy.
labview can do file i/o?