Raspberry Pi

Hi,

My name is Paul Evans, It's been 6 or 7 years since my last bot change.

Robocode is a terrible addiction and my bot SandboxDT has not been changed since 2004 but I am pleased to see it is still in the top 60.

It has recently come to my attention that a UK Charity (The Raspberry PI Foundation) is about to release a new computer on the market - this computer is the "Raspberry_Pi".

The foundation's aims are to manufacture a computer so cheap that anyone should be able to afford it (The "B" model will be $35) - their purpose is to get youngsters programming again - not just learning to use Word and Excel.

Robocode is a good fit to these aims and I would like to ask this community to help bring the joy's of programming to the next generation of youngsters.

What I would like to see:

Stage 1: An all inclusive distribution of OS and Robocode and relevent Robocode/Java documentation - The Raspberry PI will boot from an SD card into a linux OS - to get prospective coders into Robocode lets make getting Robocode up and running as easily as possible (as easy as PI).

Stage 2: As for stage one but with an ide customised for Robocode - libraries loaded/configured in an default project/robot ready to go. (BTW The compuer has at most 256MB ram (shared by the GPU) and runs a arm processor at 700Mhz).

Stage 3: Let's try and get the really young ones involved - Java is fairly heavyweight - can we have robots written in lighter languages such as Python (Jython?) or some other language or script. A distribution like this needs to be really easy to get started - most parents and teachers do not code - at primary school there may be no effective IT support.

Stage 4: Tanks, Bullets and warfare ain't to everyones taste - however Robocode has an excellent headstart in that because it has a very effective sandbox for allowing strangers code to run in - it provides an excellent environment to allow code swapping and running without risk - ideal for schools. It would be nice to see if the Robocode Physics and display could be exposed in a nice interface to allow the teaching community to develop new games - I want to encourage developers, not plagiarisers - by changing the physics of the game a teacher could force the youngsters to experiment and write their own code not just lift a bot from the internet.

It's been a long time since I've been an active part of this community - and I know I'm asking alot - I have no affiliation with the Raspberry PI or the Foundation but I have been a school governor and have been unimpressed at the level of IT skills being produced out of UK schools - I think Robocode and the Raspberry PI can help.

I you think this is a good cause please promote this page on the home page of the wiki to ensure all in the community can see it - fix up any links etc that I haven't done - feel free to take the lead. As a sweetener if the community takes this project to heart I'll give details of an innovation in SandboxDT not released to the community to date (and which I think is unique to DT)- I may even start to develop again.

Paul Evans - author of SandboxDT

Hi Paul, it has been a long time. I've also been reading about the Raspberry PI and find it a very interesting project, with a philosophy similar to Robocode, making coding accessible to everyone. It would take someone much more knowledgeable than me to make it happen, though. It would be akin to making java/Robocode run on a smartphone, with many technical limitations. A very interesting variation would be one robocode robot running on each PI, but that would take a complete redesign... Anyway I really hope someone makes it happen, even if just to finally know the secrets of SandboxDT or to see you take on the current, and apparently invincible, Robocode King. :) --ABC 12:28, 6 February 2012 (UTC)

Hi ABC - still at it I see - good to talk to an old adversary (I have a smile on my face as I type). I see some things have changed - It looks like IBM managed to release robocode which is nice - so there is a chance to make sure it works on the Raspberry PI - I think it will fit into RAM OK but I think we'll need to loose the bullets and go for a football type game if it's to have wide appeal in education - have you ever looked at the robocode source - is this even possible? -- Paul Evans p.s. no-one is invincible.

Sure thing, it has been an open source community project for a long time now, with lots of changes/fixes/improvements. But I'm not the best person to talk about it, I've been inactive for years. Flemming N. Larsen is the main developer now, and there are lots of current (or more recent) players that know much more about the current state of Robocode than I do. I know about the current King's _apparent_ invincibility though, he reminds me of another great player from a long time ago... :) --ABC 16:35, 6 February 2012 (UTC)

Hey Paul, interesting proposal! I've heard about the Raspberry PI for a while and it semed rather interesting. I don't know how much time I'll be able to find for it but I may be able to try to help. About alternative rules and getting rid of the bullets, I believe there was some recent work on the robocode engine to make it support different rulesets (i.e. capture the flag), but I think that work was incomplete and last touched over a year ago. I do wonder though, if it may be easier to make an engine mostly from scratch to support different kinds of rules though... One other thought that comes to mind, is perhaps it would make sense to make a more diverse suite of "programming games" with similar APIs, rather than just sticking to things using robocode physics. Any thoughts on those aspects? --Rednaxela 17:37, 6 February 2012 (UTC)

(Welcome back, Paul!) This seems like a really interesting project. I've also been thinking about Robocode with respect to Code Year. My first impression is the same as Rednaxela: that it may be easier and better to build a lightweight, Robocode-esque game from scratch, or even something only vaguely inspired by Robocode. I've actually had some ideas for simpler, more accessible Robocode-esque programming games for a while now, though nothing that I've fleshed out.

I feel like a graphics / naming overhaul could keep the exact same rules while leaving behind tanks and bullets. But agreed that Fnl or Pavel would have the best technical input on this. I'll post this page to my Robocode circle on G+ and tweet it to @robowiki. ;) --Voidious 20:10, 6 February 2012 (UTC)

I see Robocode 2 being born... There were attempts in the past but most of them tried to make the game even more complex, and got no followers. Besides Robocode, I also like CodeRuler which is a lot simpler (discrete commands, no trigonometry). But it never had a community as big as roborumble. --MN 21:55, 6 February 2012 (UTC)

And some people don´t like LiquidThreads... :P --MN 21:55, 6 February 2012 (UTC) --Rednaxela 14:43, 7 February 2012 (UTC)

Heya Paul. Chase, probably don't know me. Good to see people interested in a new project. I have tried a few small and discrete 'robocode' like projects myself. Roboflight, etc. These never went far, despite some of them working fairly well (at the time). So I know something of the requirements to make a new one. The ARM architecture is very nice in my opinion. Due to the simplicity and cheapness of reformatting and ghosting a SD card, not even sure a sandboxed language would be required (like java). But just my 2 cents, always exciting to start a new project. — Chase-san 04:00, 7 February 2012 (UTC)

As a comment, having discrete moves in a game doesn´t make it any less challenging. CGOS is a good example of the opposite. Although it is definitely not for beginners. --MN 14:34, 7 February 2012 (UTC)

I am on rewriting from scratch with other language. I don't really know about this, but I heard that Android's Dalwik (or whatever it spells) is one of the performance limiting factor on the system. If that is true, and since Robocode is very performance intensive, I don't think we should use VM language.

I just started playing with CodeRally (part of CodeRuler) I think it is nicer for beginner than Robocode (though I find it limiting in some way, especially when an angle is an integer. Much like how JuniorRobot is right now). I think CodeRally idea of throwing spare tire is very good replacement for Bullet and War, though. --Nat Pavasant 12:36, 7 February 2012 (UTC)

I also thought in CodeRally as being good for beginners. The theme is appealing. Although not as good for competitive programming. --MN 14:34, 7 February 2012 (UTC)

About using a non-VM language Nat, I don't think performance would be a good reason to do so. If robots are written in the non-VM language, then then it would be very difficult for users to trust running third-party robots. What's a solution to that? Have the bots written in an interpreted language while the engine is still in a non-VM language perhaps. But then you don't really get speed benefits anyway. So, I don't think performance could possibly be a good reason to use a non-VM language in this case. Btw, Android's VM is probably not relevant to this, because so far as I understand the Raspberry Pi will more typically run a more usual Linux installation (an android port to R-Pi is probably possible, but likely to happen later rather than sooner), so something like OpenJDK Zero (a version of OpenJDK that can, for one, run on ARM), is a more likely VM if Java were used. --Rednaxela 14:43, 7 February 2012 (UTC)

I don't really know about performance, so I compare it to Android since both are ARM. About the trust, I just follow what Chase said above -- run and re-format the system. I don't know much into these things anyway. --Nat Pavasant 14:49, 7 February 2012 (UTC)

Well let me clarify. While its true that's what I ment, I am up for anything. However some may not want to do that, I mentioned it out of hand because it actually seemed like a viable solution to the problem, but was just my silly 2 cents. Not to say it is something that you would actually want to do. What if a robot flashes the binary blob or SD's boot sector with something. Not everyone has the technical expertise to repair either of those. But the project sounds fun, regardless of what environment is chosen. — Chase-san 17:02, 7 February 2012 (UTC)

First thing is to see if we can get an SD card distribution with all the software and documentation to get a newbie started - anyone know of a Java Primer that can be included to get them started? This should not be too difficult to achieve (no coding required I think) - but it has to be an easy one stop shop to capture the market (and not rely on an internet connection from the Raspberry. Where would be distribution be kept?

BTW - off message but where do you get the latest bots from - I want to see DrussGT demolish DT! - as far as I can see the repository and this site does not have the version that is in the rumble. Paul Evans

We could likely use Fedora based distro for it, since all the hardware is the same, don't even need the installer. Get the distro, add the packages, copy the disk image.

Also, you can find all the rumble robots here: http://robowiki.net/wiki/RoboRumble/Participants

— Chase-san 18:26, 7 February 2012 (UTC)

Just a thought, if we use a pure Robocode solution it would be nice to have a static version of the wiki onboard that students can use for offline reference. Maybe some sort of 'sync' mechanism that can be used for updating the pages when internet is connected as well. I've also been looking at the Pi for some time, although more as a replacement for a microcontroller in embedded applications where it would be nice to be able to write components in Python and have USB interface with plenty of easy datalogging available. --Skilgannon 09:43, 8 February 2012 (UTC)

Yeah, actually I was looking around and was thinking BlueJ looks like it might be something to consider as well. I especially like the look of that graphical class structure. I have not tried it yet, but looks like it might be better to just package it instead of our own editor. — Chase-san 12:30, 8 February 2012 (UTC)

Okay, update I tried BlueJ. It is a very simple coding tool, and I think that it is perhaps a bit different from what we are used to. First it can do these fancy graphs, but only if all classes are in the same package. So the tool still needs a little work, but it is probably simple for beginners.

I decided to do a little test and imported Nene into it, which is by no means a small robot. It seems to build the graph OK, but there were a few classes I had to open and resave to get them to register.

http://file.csdgn.org/image/nene_graph.jpg

Next I could not determine a way to move classes between packages, not the end of the world, but I don't see myself using it. Importing the robocode library was fairly easy and straight forward, the actual programming UI had what looked like colored blocks. Making it easier to see what is part of what block, which is kinda awesome. But otherwise it is a very simple IDE like our built-in editor, except with a nicer interface. It has some kind of testing system, which might even be able to fire up robocode and test the robot with the correct test class.

— Chase-san 19:48, 8 February 2012 (UTC)

What a great idea to have Robocode on Rasperry PI! :-) I have been looking for a perfect excuse for buying one! :-) Well, first of all, Pavel did a great job with the modularization of Robocode. But I do expect that we need to adjust Robocode even more with cleaner interfaces in order to e.g. replace the UI.

For quite some time, I have been considering building a completely new version of Robocode from scratch, where bots run in individual processes (instead of thread inside the same JVM), and the communication between the game process and bot processes would be plain IPC based with a simple (Robocode specific) protocol using only STDIN and STDOUT. The process would still need to run in a virtual machine (sandbox... using e.g. the JVM, .NET, Mono) in order to keep the system from harm from evil robots, but if the end-user accepts, the bots could be written in any language (but not necessarily run on any system, if e.g. C/C++ or machine code is used).

We could even wrap the IPC into socket communication as well, meaning that bots could battle across different machines and be run on the net. The game/server, the bots, the UI etc. should be totally independent modules and only communicate through a simple, but fast protocol. This way they could be written in any language and also be replaced. For example, I could do an standard 2D view, and somebody else could create an alternative view using 3D graphics etc. It would be great if Robocode could run "anywhere", on the net, and across multiple machines. I should also love to extend the game with new features, like obstacles, different game types, real tournaments etc. However, all this would mean that the new version (Robocode 2 - The Ultimate AI Challenge) would not be compatible with the current Robocode at all. However, we could get rid of old stuff and limitation present with the current version of Robocode. Personally, I think we/I will need to go into this direction if Robocode should survive in the long run and be even more attractive. :-) However, this will require some time to do, and this would "steal" time from working on the current version of Robocode (1). --Fnl 19:33, 27 March 2012 (UTC)

I would be happy to help out. Been trying to design/create/get people interested in a Robocode 2 for awhile now. :-D — Chase-san 01:56, 28 March 2012 (UTC)

New project from scratch? It's rare event now days:) I'm in too:) --Jdev 17:05, 28 March 2012 (UTC)

I'd love to compete in a Robocode 2. First, I'll say that I don't think compatibility with Robocode 1 is on anyone's wish list. My dream for a Robocode 2 would mainly involve:

• Learn from the things we don't like about Robocode 1, like the arbitrary scoring algorithm, some of the poor API design (JuniorRobot, RateControlRobot were good steps in this direction).
• Add a couple carefully designed features, like random obstacles and a secondary gun that could shoot over obstacles.

Just 2 or 3 small game play changes could open up worlds of new strategies and programming problems. I like a lot of the ideas Fnl puts forth above, architecture-wise, and there's no reason not to re-design all the code with a clean structure. But for me, my main focus would be on well designed game rules that allow for interesting bot programming. Support for any programming language, ability to run matches between remote computers, making it extensible so as to allow any rule set, that all sounds neat, but also sounds like a ton of work that isn't necessarily going to give me more of what I want as a competitor. --Voidious 20:53, 28 March 2012 (UTC)

That architecture overhaul would solve a lot of the issues we are currently facing, like unconstrained heap usage and incompatibility with other languages. Would also combine other ideas that appear from time to time, like Virtual Combat.

But there are some things I would advise to keep. Imperfect information (bullets invisible to radar), continuous move set (doubles), skipped turns (real-time), melee/team and sandboxed execution. These are what make Robocode unique as an AI game.

The drawback would be leaving all those thousands of Robocode 1 robots behind. A very serious drawback. --MN 22:52, 28 March 2012 (UTC)

Hey guys, Hardware will only continue to get cheaper and more powerful. When I think of making use of a raspberry pie (and I have :), I wish I could use all that Robocode AI code I spent so much time on, and port it, to use in real hardware/bots. (eg: toy Bots running robocode2 code) Could the suggestions Fnl made for Robocode2 structure possibly support this? perhaps more difficult :Could the radar in Robocode2 be a virtual webcam? I realize this idea might be seen as far out there; but the joy of building a virtual robotank in robocode, would be limitless if it could easily be brought to life.. Not only could Raspberry Pie /robocode2 be a tool for learning, but also a way to make your own toy Bots.. or something practical like a vacuum-Bot.. ect.. To think of it: My son has a bunch of cheap broken rc cars I'd love to strap a Raspberry Pi/webcam to :)

How far fetched would this be ?? -Jlm0924 17:12, 13 April 2012 (UTC)

Building a real radar (radio or sonar) is waaaay harder than using a Java API. Building an image recognition based radar (webcam) is even harder. Try to imagine how you would estimate distance with a webcam. Not counting other technical challenges like distinguishing robots from other objects in the image.

Most real robot competitions, like Robot Wars, plug radio emitters on top of robots to make it easier for other robots to track them. -MN 20:37, 13 April 2012 (UTC)

Not out of reach, but definitely challenging. Just wanted to point how hard it is. Bleeding edge robotics technology is already achieving that. With 2 webcams, it is possible to analyse the difference between the 2 images and triangulate the distance. Requires a lot of AI processing to isolate the desired object in each image. I only wonder how this would be done in real-time with Raspberry PI. -MN 19:04, 17 May 2012 (UTC)

yeah, I realize web cam use would likely be out of reach.. ( and introducing hardware options to robocode would be a drastic change in direction for robocode, so I won't dwell on this path.. but the Rasperry pi being a pc platform , offers so many possibilities..

eg: usb dongle's average $5 a piece,, cheap, even if you need 3 of them.. They can be used for location tracking acording to wikipedea; quote:" Real-time location systems (RTLS), are used to track and identify the location of objects in real-time using “Nodes” or “tags” attached to, or embedded in the objects tracked, and “Readers” that receive and process the wireless signals from these tags to determine their locations[15]" -Jlm0924 15:01, 14 April 2012 (UTC)

A much more feasible approach. It would even need to throw tracking data away to mimic a robocode radar scanning only in one direction. -MN 19:04, 17 May 2012 (UTC)

---

Just placed my order =) --Skilgannon 17:46, 17 May 2012 (UTC)

Nice! Any plans for it yet? --Voidious 20:34, 17 May 2012 (UTC)

Possibly adding a webcam and putting it on my quadcopter, streaming the data either over wifi or to disk, then doing Structure From Motion to rebuild 3D models - it's quite similar to what I'm doing my masters on (robotic mapping with laser scanners). --Skilgannon 20:38, 17 May 2012 (UTC)

FYI... I've just installed the latest version of RoboCode on my Raspberry Pi and it works great. Performance is understandably a bit slow. 100% CPU usage during battles, but memory still has 80mb free. This was using the Raspbian (debian) distro. --walker 09:45, 13 Aug 2012 (UTC)

Cool! Does the app itself run at a usable speed? How about the editor? And I'm just curious, any other plans for your Raspberry Pi? --Voidious 14:29, 13 August 2012 (UTC)

I found it to be very usable. I am running the unit headless at the moment using RDP to the X11 desktop. There is no problem with the editor or compile times. The battle display was quite choppy when running contests but that is to be expected over the RDP connection. I should note I only ran battles between two fairly simple bots. I'll be giving it a better workout with a directly connected display and larger battles within the next few days. --Warcher1 17:46, 13 Aug 2012 (UTC)

That's great! I guess maybe we could start working on Paul's "step 1". Man, I suddenly really want one of these. Still no idea what all I'd do with it, but maybe I'll just order one. --Voidious 20:11, 13 August 2012 (UTC)

Yep, why not? For $35 you can't go wrong. Order to delivery time is coming down now. I have heard some people say 3 weeks. (Still a long time... I know, but better than the 3 months it took for me.) Here are some better stats using X directly on the video board. I ran a battle with 10 of the sample robots and got 5-17 TPS depending on how many robots were alive at the time and 1-2 FPS. It showed 14-20 mb used. The free command showed 128mb free. CPU was, of course, pegged during the battle but had lots of headroom during editing and setup. I didn't measure startup time but I would estimate that it was about a minute. I didn't get sound to work this evening but I haven't verified that it was working with anything else yet either. When I run RaspBMC I get sound via the HDMI port but RoboCode is running under Raspbian (a different distribution of Linux.) I'll be working on getting sound working this week. --Warcher1 20:46, 13 August 2012 (UTC)

I'm trying to run Robocode 1.7.4.1 on my raspi, but I'm getting OpenGL errors. Which versions of Robocode and Java are you using? And did you get your Raspbian from the raspberry pi website or the raspbian website? Thanks --Skilgannon 07:24, 14 August 2012 (UTC)

Ah, disabling the OpenGL in the robocode.sh seems to have fixed it. It seems the Raspberry Pi has a Robocode CPU constant of 705ms - that's about 100x slower than my i5 laptop. The code editor seems REALLY slow - scrolling up and down in MyFirstRobot.java hangs for several seconds. Minimised, Walls vs. MyFirstRobot runs at about 45TPS, which is pretty horrible. It seems the ARM doesn't like java that much, as I don't think it is quite as bad when it comes to python or c. --Skilgannon 07:36, 14 August 2012 (UTC)

Did you keep the RAM at 256 or 512 in robocode.sh? If it's trying to grab as much/more RAM as the system has, it might be paging out like crazy. --Voidious 14:38, 14 August 2012 (UTC)

I changed it down to 140MB. This was just sample bots, so it only took about 20 MB total. --Skilgannon 16:40, 14 August 2012 (UTC)

I'm not near the Rpi this morning so can't speak about the OpenGL support, but I know that I installed openjdk 1.6. I downloaded Raspbian directly from the Raspberry Pi site, not from the Raspbian site. My experience with Robocode is minimal so I defer to you about what is acceptable performance. I definitely don't expect it to be as responsive as my full computers. --Warcher1 9:22, 14 August 2012 (UTC)

Considering Robocode came out 10+ years ago, it's funny to think that their computers probably weren't much faster than this. =) Somehow people still got addicted... --Voidious 13:48, 14 August 2012 (UTC)

I'd say they were about twice as fast at least, surely they were using Pentium 3s by then? Apparently the RPI is as fast as a 300MHz Pentium 2. --Skilgannon 16:40, 14 August 2012 (UTC)

You're right, I had a P3 as my office machine in 2000. A P2-300 that I got in '98 is exactly what I had for a personal machine until 2002 or so, but I guess I was behind the times. --Voidious 17:27, 14 August 2012 (UTC)

Ordered mine yesterday, so I guess I'll have it in a couple-few weeks. Contemplating writing a fresh, lighter weight programming game that would run OK on it. No idea if it will come to fruition, and don't have any game design ideas I'm in love with just yet. Something lighter weight than Robocode but with potentially fancier graphics seems to fit the bill of what the Raspberry Pi is capable of. Looking into Lua as the language bots would be written in - embeddable, fast, open source, and easy to restrict it from accessing files and network. Not sure if that means I'm stuck with C as the host language or not, still gotta figure that out. --Voidious 21:41, 15 August 2012 (UTC)

Got mine on Thursday and got to some tinkering over the weekend. I've got a basic prototype working with a bot controlled by a Lua program that's loaded at run time, a basic physics model and bot movement API, and super simple graphics drawn with OpenVG. Hoping I can turn this into something cool and usable over the next few weeks. =) --Voidious 19:24, 4 September 2012 (UTC)

Been having a ton of fun hacking away this week. Still at least a couple weeks away from anything polished enough to release, and support for rich multi-bot battle gameplay might be further out than that. I'm trying hard to keep it as beginner-friendly and immediately gratifying as possible. Going for dead simple APIs and easily configurable gameplay, which I think would be great for educational settings. I must say this Lua stuff is pretty damn cool. --Voidious 16:09, 7 September 2012 (UTC)

I can tell you that a dead simple API would be a godsend for me in a high school educational setting. I've never used Lua before, but from the examples on Wikipedia, it seems like it'd take less heavy lifting than Java to get students into (part of why I'd love it if Python were available for Robocode to get students started). I don't have a bunch of Raspberry Pis though... would this project of yours be cross platform and runnable on a desktop machine? --Tkiesel 17:31, 7 September 2012 (UTC)

Yeah, the Lua parts and the C++ game engine would compile on any platform, but the graphics I'm using right now are some Raspberry Pi specific OpenVG code, so I'd just need to rewrite that with something more common. I definitely intend this to be cross-platform, but to start with I'm focusing on the Raspberry Pi. I'd never used Lua before either, so I'm kind of learning the language itself on the fly too (as well as boning up on my C++, which I hadn't touched in a couple years =)). So far I like Lua well enough, and the way it's designed to be embedded in C/C++ is just perfect for a programming game - you can easily load each bot in its own sandbox, and I should be able to pretty easily modify it to restrict network and file access like Robocode does, so you're safe running other people's bots. And Lua has a tiny footprint, and seems pretty fast, so the whole thing should be a great fit for the Rpi compared to a big desktop Java app like Robocode. --Voidious 17:52, 7 September 2012 (UTC)

Awesome. I'll drop you an email, since there are some things I'd like to discuss if you're game, and a tangled, long form discussion would just be a mess on the wiki here. :) --Tkiesel 18:02, 7 September 2012 (UTC)

Voidious, I'm curious what kind of performance you're getting with Lua on the Raspberry Pi. Is there any chance you could port the Robocode CPU constant test as a sort of benchmark? I know that Lua's one of the fastest scripting languages, and that it has a low memory footprint which should make it much happier in the cache-limited ARM environment, but I'm curious how much of an improvement it will be over a JIT compiler equipped JVM. --Skilgannon 19:44, 7 September 2012 (UTC)

Sure, I'll give it a shot, though I'm not familiar with that code at all. Right now things are running pretty fast, but all the heavy lifting (physics, collision detection) is in C++. I haven't written very complex bots yet. ;) But with a sample.Crazy-esque bot and my basic physics / wall collision detection, it seems to be constrained by the monitor's refresh rate and uses 25% CPU, or if I switch to paint every 10th tick, that still seems to run at the monitor's refresh rate (so like a few hundred TPS) and uses 80% CPU. --Voidious 20:00, 7 September 2012 (UTC)

Ah, one more thing, are you using LuaJIT or just vanilla Lua? --Skilgannon 20:18, 7 September 2012 (UTC)

Just regular Lua (5.2.1) right now. Didn't know about LuaJIT, but I'll take a look. I thought the programs were compiled when loaded, anyway, so I didn't think there was much to JIT, but obviously I'm no expert on this yet. --Voidious 20:22, 7 September 2012 (UTC)

Lua is a bytecode interpreted language I think. It might get compiled to bytecode, but the bytecode is interpreted. LuaJIT iirc, compiles the lua code to machine code on the fly (like well a JIT, go figure). Chase-san 03:40, 8 September 2012 (UTC)

Ok, so in a pure C++ calculation, I get a CPU constant of 640m. If I replace the inner loop with a call into Lua, its about 4x that (2400m), but that's not fair because it also adds ~13k calls into Lua. If I run the whole loop in Lua, I get about 2.5x the C++ constant (1600m). So it appears Java's pure CPU calculations aren't particularly slow at all. I bet the Robocode graphics take a huge hit by not currently using the GPU. And while I imagine Robocode itself is a bit heavyweight, the CPU used by the bots themselves still surely dwarf that of the engine. --Voidious 05:18, 8 September 2012 (UTC)

Reached a milestone today in terms of having something really playable, so stopped and worked on a more sophisticated bot. Didn't take long for me to bring the Raspberry Pi to its knees and see like 1 FPS with a path-finding algorithm. =) But with a little care I was able to do what I wanted and make it run decently. It's pretty clear that probably nobody will be doing the type of hardcore bot development we're accustomed to on the Raspberry Pi, but that's ok. The current game play mode I'm starting with should still be plenty usable. Having the effects of inefficient coding so amplified may not be such a bad thing in a Raspberry Pi / educational setting, either. I might not even want to have the CPU-per-tick limitations in this mode.

I also got a lot more familiar with the Lua language itself. There are definitely some oddities to it, like the way tables are used to support both collections and pseudo-OOP support, but all in all it's pretty fun and easy to work with. --Voidious 00:52, 9 September 2012 (UTC)

Posted a quick video of what I've got so far: [1]. Definitely interested in any feedback. I've completed the first phase of game play that I had in mind, so I'm sort of at a crossroads as to what to do next. I'll probably start on running multiple bots at a time and experimenting with game play rules for battles (energy, shooting at each other, etc). But I think I could do some pretty cool stuff expanding on the single player / programmable stage aspect, too. --Voidious 04:58, 10 September 2012 (UTC)

Looks really cool! I'm wondering if perhaps you could make it like a 'Tron' sort of game, where you are given a certain amount of wall you can leave behind to trap the enemy. Perhaps even something like the energy drops in Robocode, where you lose energy by hitting enemy wall and by leaving wall behind, then gain energy if they hit your wall. --Skilgannon 14:01, 10 September 2012 (UTC)

Hmm... I like the idea of coming up with game rules other than "shoot at the enemy and try not to get shot by him", but it also scares me a little to stray from it, because I'm so familiar with it and I know it can be tuned to a good balance. My biggest fear is that the game rules I come up with turn out to be solvable - ie, there is an optimal algorithm that can't be improved upon. That might be the case with the Tron rules thing. But you've definitely opened my mind a bit, I'll give this some thought. --Voidious 15:50, 10 September 2012 (UTC)

Another small update on execution speed. I've now got multiple bots running at once and pretty nice collision detection / physics with walls and between bots. With 5 trivial random movement bots, I get 400-500 TPS if I disable the graphics. Even my path-finding bot on the complex maze stage gets 100+ FPS with no graphics. I was down to like 40-45 FPS with the graphics and 5 bots, but back up to full smoothness at 60 if I use 1 circle instead of 3 for each ship. =) It seems a bit crazy that Walls vs MyFirstRobot ran at 40 FPS minimized. I really wonder if there is some graphics processing stuff still going on, or if Java is just that slow on the Raspberry Pi for now, or if the Robocode engine and/or Java libraries are just that heavy compared to doing things closer to the metal in C++. --Voidious 04:11, 12 September 2012 (UTC)

Lol, I'll have to figure out what's up with the graphics performance here - here's Quake 3 running on the Raspberry Pi. [2] :-P I'm using some OpenVG code someone posted on the forums, but he's got a more complete library that I'm going to switch to soon. I thought this should be GPU accelerated but maybe I'm doing something wrong. --Voidious 04:48, 12 September 2012 (UTC)

I suspect RC is still doing graphics stuff, because the title bar when minimised says "[Robocode: Turn 687, Round 32 of 35, 48 TPS, 2 FPS, Used mem: 12 of 128]". If you want to eke out some more performance on the Lua side, try using LuaJIT - there are precompiled packages an apt-get away on Raspbian. In benchmarks I've seen it getting similar performance to the JVM and even gcc compiled C++, and it's still really lightweight. It seems to be a drop-in replacement for Lua. Although I just checked my Pi, and it seems it's already installed, so maybe you're already using it? =) --Skilgannon 07:35, 12 September 2012 (UTC)

I'll definitely take a look at LuaJIT at some point - perhaps when I'm running all-day benchmarks for a new bot. =) But for now I'm not worried about bots running ~twice as fast and I don't think that performance improvement would affect the design of anything much, so I'll just stick with what I have working. LuaJIT is also MIT license though, so I would be able to take the same liberties with it, like modifying it to restrict file and network access or whatever else. (I'm definitely on regular Lua - the C API is totally different for LuaJIT.) --Voidious 13:40, 12 September 2012 (UTC)

Twice? The numbers I've seen suggest much more than twice as fast once the code starts doing any sort of interesting algorithms ;) --Rednaxela 14:19, 12 September 2012 (UTC)

Hmm, maybe I will check it out sooner. They have benchmarks on their site, on various CPU architectures even. Lua vs LuaJIT on ARM But it will probably wait until after I try to figure out my graphics framerate issues and allow bots to see each other. =) --Voidious 14:31, 12 September 2012 (UTC)

Regarding the attempts at using Java on the RPi, what specific version of Java are you using? Maybe it's a version without JIT support? Versions with JIT on ARM should be fairly readily avaliable I believe. Also, is your version of Java compiled to use the hardware floating point unit? I know many builds of software for ARM, build for compatability for older/simpler cores without FPUs, and I also know that Robocode relies very very heavily on floating point arithmatic. --Rednaxela 14:19, 12 September 2012 (UTC)

raspberrypi.org has just announced that they are supporting overclocking of the ARM and GPU chips. They are now allowing upgrading the 700mhz CPU clock to 10000mhz. The Robocode that I installed (1.7.4.1) is now giving performance at about 26 TPS and 3 FPS out of the box. --Warcher1 21:23, 19 Sep 2012 (UTC)

Interesting. I've updated and overclocked to 900MHz and it seems to have made a huge difference, probably because the core speed (ie. RAM) is almost twice what it was before. I'm now getting 75TPS, 6FPS minimised with Walls vs Crazy. My CPU constant has also dropped from 700ms to 520ms. Maybe there were also other changes that helped. I'm using the OpenJDK Zero VM (hardFP), Robocode 1.7.4.2 --Skilgannon 13:44, 20 September 2012 (UTC)

Hmm... interesting that you get that with Zero, as that has no JIT at all IIRC. I wonder if it would make much difference if you tried OpenJDK Cacao... --Rednaxela 14:24, 20 September 2012 (UTC)

That's when viewing the battle, right? I wouldn't be too surprised to hear that Java's non-GPU accelerated graphics are just painfully slow. And if it's also slow when minimized, I have to guess (as suggested above) the culprit is some stray graphics processing that's still going on. 60 TPS with two trivial bots is not even in the ballpark of what I'm seeing in my new game, and I don't think the complexity of the basic game rules (physics, collisions, objects on the screen, data sent to/from bots) is that far off at this point.

It would be nice to see if -nodisplay or running a battle with the Robocode control API (eg with RoboRunner) ran at a decent speed. Maybe that would truly disable the slow graphics code. And if it runs OK like that, maybe we could write a Raspberry Pi graphics wrapper that uses the control API to run battles and draws some simple graphics with OpenVG. I wonder if stdin/stdout between a C wrapper and a Java program running battles with the control API could do 60 FPS? Or maybe try some JNI, which I have some experience with, but not for a while and I'm certainly no expert. I could probably get something like the stdin/stdout model going with a few days work now that I'm familiar with OpenVG, though I'm kind of obsessed with writing this other game at this point. --Voidious 19:22, 20 September 2012 (UTC)

Actually, looks like there are or will be ways to do OpenGL ES or OpenVG from Java on the Raspberry Pi, so that's probably a cleaner solution, eg [3]. Plenty of talk of AWT/Swing being really bad on the Rpi. --Voidious 19:37, 20 September 2012 (UTC)

I should mention that the stats I got above were while running through X... so really bad video speed. --Warcher1 23:20, 20 Sep 2012 (UTC)