View source for Talk:Raspberry Pi

There has now been a new version of the Pi released. I was going to get one as they are still dead cheap. I might run some rumble on it and see how it does. It apparently has a newer quad core CPU that runs at 900mhz and due to improved architecture has approximately 6x the power of the original Pi, plus the machine now has a gig of ram.

I'm going to give it a go and will report my findings (once I get one!)

[1]

If it all goes well I am in the process of getting my GA framework up and running where I will be able to run it on the PI2 and improve my bot (hopefully)!

6x a P2-300 is still pretty much crap by our standards. :-) But it sounds like a fun experiment, keep us posted!

It doesn't need to be lightning fast if you can leave it on all day every day running something. It only consumes around 4 watts compared to 500 for a desktop PC so its not going to break your bank to do so. I dunno if the power to wattage ratio is better than a desktop PC though! Are desktop PCs 100 times faster than a RP2? I would have thought not!

I can go to work, leave it running which is not what I would do with my desktop! :)

Sure, sure, let me know when you're willing to wait 4 days for what takes an hour on your desktop. :-) I've done GA on my quad core Core i7 (6-8 threads running safely) and let it run for days. I cringe at the thought of a cluster of P2-300s doing the same amount of work... weeks? years?

CPU power aside, I'd be curious to hear about your GA setup. I've looked into, but never done real battles with Robocode. I've only evolved guns with WaveSim. To evolve movement, I imagine you have a test bot loading the variable code from a .properties file, unless your GA code is compiling and outputting JARs, which is the ideal but a pain.

FWIW, GA with full bots is not hard with BerryBots - I've even written an example to solve a maze: http://berrybots.com/wiki/MazerEvolver .... But, alas, the automation API doesn't support the Raspberry Pi (yet?). The big hurdle is that the automation API supports user interaction - you specify what fields you want and it prompts the user with a GUI. I'd like to do an ncurses version for the Rpi at some point, but who knows if I'll get around to it - I'm more interested in the web UI at this point.

Hah I'm not so sure it will be that slow. We shall see I guess. Will be fun to find out whatever the result! :)

As for the GA I don't have it running yet, but I have in the past for previous test bots. This time will be similar but better I hope. Basically I have my own framework for testing a bot similar to Roborunner / RoboJogger but I can run diirectly from other code. This is all in C# just because its what I'm most comfortable in using (especially for threading). I plan to use this framework to run tests against bots as you describe by programmatically updating a settings file in the bots data directory. Do a run for every individual in the population, evolve, try again. This will be very slow to run I know. But I will probably evolve on a subset of the robots in the RR, not sure how many yet. You have a good idea of what gives good coverage? I dont want the GA to specialise against just a few bots as it will probably decrease performance vs the rest! :)

I will be evolving all parameters in the bot at once. GA is great for doing this, I think that doing movement/gun independently has advantages and disadvantages but I think the two are not mutually exclusive and the GA might find some interesting ways of setting variables such as firepower depending on how your bot moves compared to your target - and your targets will adjust movement & position depending on your position, which affects your targeting. We shall see!

If I get time I will do a write up of my stuff and maybe release the source for my framework if anyone isn't wanting to use RR/RJ for some reason like me! :D

Back of the napkin calculation: 17 years since I got my P2-300 = 11 doublings (Moore's Law) = 2^11 or 2048x speed for modern desktop vs original Rpi /= 6 for Rpi 2 = 340x. =)

The P2-300 is Single core, The Cortex-A7 is Quad core .
The P2-300 has 300 Mhz, The Cortex-A7 has 900 Mhz.
The P2-300 is CISC, The Cortex-A7 is RISC.
The P2-300 consumes 18.6 Watts, The Raspberry Pi only 4 Watts.
In other words yes the Cortex-A7 is better than P2-300.

Figured I'd take this to a separate thread. =) Posted another couple of vids with progress on the Raspberry Pi game I'm working on.

• part 1: sample stages, battle mode
• part 2: stage and bot APIs

Still a lot to do but I think it's coming along pretty well.

Nice, looking neat :)

Wonder how strategies will play out... hmm

Man, you are totally of the hook :). Looks indeed very neat. The race looks and sound as it could provide a lot of fun and maybe some nice pathfinding programming.

Well done!

(Sorry, gotta take this back to LiquidThreads.. =))

If anyone's curious, here's some TPS measurements (with graphics off) of Lua vs LuaJIT on the Raspberry Pi and my 2009 MacBook Pro 2.8 GHz. RandomBot is a trivial bot like sample.Crazy, BasicBattler is a slightly non-stupid bot with a simple Minimum Risk movement and random linear gun.

• 2x BasicBattler
  • Rpi Lua: 343
  • Rpi LuaJIT: 632
  • MBP Lua: 5967
  • MBP LuaJIT: 19101

• 8x BasicBattler
  • Rpi Lua: 44
  • Rpi LuaJIT: 88
  • MBP Lua: 766
  • MBP LuaJIT: 2377

• 2x RandomBot
  • Rpi Lua: 782
  • Rpi LuaJIT: 1053
  • MBP Lua: 17781
  • MBP LuaJIT: 28154

• 8x RandomBot
  • Rpi Lua: 119
  • Rpi LuaJIT: 182
  • MBP Lua: 2429
  • MBP LuaJIT: 4159

Obviously the LuaJIT is far superior in speed.

LuaJIT vs Lua

• 2xBB
  • RPI: x1.84
  • MBP: x3.2
• 8xBB
  • RPI: x2
  • MBP: x3.1
• 2xRB
  • RPI: x1.35
  • MBP: x1.58
• 8xRB
  • RPI: x1.53
  • MBP: x1.71

Even considering a margin of error, it seems the x86/amd64 version is either more mature or has a more leverage-able machine code (assuming your mac book is intel rather then PPC based).

It seems to scale up on complexity. Be it more bots or more complex bots.

I think there might be a fixed, constant overhead each time you call the Lua code, so the actual advantage within the Lua code is actually much higher. From the results with RB, it seems that LuaJIT also has a smaller overhead constant.

About the difference between AMD64 vs ARMv6 instruction set, one is CISC other is RISC, so the CISC will benefit more from the pure assembly components that were part of LuaJIT because more suitable instructions can be used to do multiple steps in one instruction. At least, that's my guess.

Oh, definitely the advantage is much higher in the pure Lua code. The more time being spent in Lua code, the more you'll gain from LuaJIT. I wouldn't be surprised to see more like 10x-20x gains with really complex bots. Some of the benchmark comparisons on luajit.org go as high as 50x.

I'm a little surprised 8x RB has a higher gain than 2x RB. The game engine is pretty fast, but some of it is <math>O({n^2})</math> (the line of sight and ship-ship collision detection), so for something like 8x a trivial bot, the engine is using a lot more CPU, which obviously gains nothing from LuaJIT. But I guess it's also sending more event data to the bots each tick, too (even if it's going unused here), which is sped up by LuaJIT.

Good point on RISC vs CISC, I hadn't thought of that. It could also indeed just be more mature on x86.

Interesting results.

Regarding some of the O(n^2) time things, I wonder if it would be worth trying to improve those via methods that subdivide the area (either tree or grid), to avoid having to do a check for each bot, for each bot. Of course, the question is how many bots does it take for the cost of maintaining the data structure to be made up for. I suspect more than 8 unfortunately.

It also depends heavily on the stage configuration - the above tests were on empty battle fields with no walls for checking line of sight. It's fairly well optimized as it is - for line of sight, it ignores the outer walls, doesn't re-calculate AxB and BxA, and line intersections involve no trig at all. And circle/line and circle/circle intersections, for collisions, will short-circuit quickly most of the time.

I considered trying some fancy improvements to the line of sight stuff - sorting the walls by how frequently they obstruct vision would be a big one - but as it will probably be quickly dwarfed by the CPU power required by bots, I figured it was better not to waste time on it and to keep the code simple.

One question just came to mind. Are you using floating point positions in BerryBots? If so I wonder if integer based (but still with better resolution than display pixels) would be much faster.

Yeah, it's all floating point. That's an interesting thought... Just with integer math being faster than floating point? And I guess it might enable some algorithmic optimizations if I knew it was a grid of fixed size, but I'm not sure.

But I think folks like floating points (I know I do in Robocode). And while it might speed up the physics engine significantly, it wouldn't necessarily speed up bot algorithms. And I think it might make bot programming more complicated having to round everything in your code, at least with the current game rules.

I honestly don't feel it makes bot programming any more difficult really. Bots could still use the floating point if they want to and won't suffer being less accurate in a significant way. Consider that current robocode fields are measured with a size no bigger than 1200x1200 or so units, and that a 32-bit integer can store 1200 times one milion just fine. In robocode I doubt being one millionth of a unit off has ever mattered. Is more resolution really needed? When dealing in absolute coordinates it's more resolution than 32-bit floating point would give (24-bit mantissa).

Well, as a bot author, I like everything modeled in my code exactly as it is in the game physics. (I know you of all people can appreciate that. =)) But actually you're right, with high resolution and doing all conversions on the host side, it could be transparent and it would be faster. I'm just not sure how much faster, and it might be a fair amount of work. So I'll consider it and do some investigation, but it's probably not high priority for now.

I think the bots will quickly outweigh the game engine in terms of CPU time and that the users who care most about uber-fast TPS are probably the same users with pretty complex bots. I do want the game engine itself to be really lightweight and fast, but at some point it becomes more a matter of personal pride than actually adding value to the game. =) And I'm trying to curb my whims and stay focused on a nicely prioritized to-do list.

What would really make things faster is if the game rules didn't require bots to ever do trig or sqrt's. But it's too late for that at this point. Maybe in the next game... ;)

Actually, speed in bots has more to do with game tree size (complexity) than number representation. i.e. chess has an 8x8 discrete (integer) board and the top AIs in the world are incredibly complex and slow.

Want to make bots run fast? Add a real-time constraint (skipped turns), like Robocode has.

Sure, I understand that. I more mean that at least your CPU time can be spent on game related strategy stuff instead of doing trig and sqrt's. :-)

Just wanted to say this hasn't died... I've been working on it a lot and it's actually in a pretty stable and releasable state. I'm mainly waiting on clearance from work that I can release it. I don't expect that to be a problem (gone through the same for Robocode bots / WaveSim before), but you never know...

A couple weeks ago I ported the graphics to SFML and I've got it building / running on Mac and Linux now. I want to make a full GUI for the “real computer” version, but right now each match is just launched from the command line like the Rpi version. Teams, both weapons ;), all the events, security stuff, stage-loaded ships, graphics, packaging and loading bots/stages with or without source, and bot / stage APIs are all fleshed out and working smoothly. I tried writing a slightly decent gun today and it's definitely not at all a straight port of concepts from Robocode-land. I think the team setup is pretty sweet, and with one more feature to the stage API you could write a pretty legit CTF stage, which I think would be pretty cool.

SFML supports Windows too, but my use of Unix tar for packaging/extracting bots doesn't. So it will be a little work to support Windows, probably using zlib for zip stuff. Main issue though is that I don't even have a Windows machine to work with. Maybe I’ll grab a copy of Windows later if I’m feeling really dedicated to this project. :-)

Yay! Finally got permission to release this. It's pretty complete as far as game play and what features I wanted for the Raspberry Pi version, and all the same is working on Mac/Linux. So I'll get everything together and release that version first. Folks could certainly start making bots and stages, sharing them, and having fun with it. But there are still a handful of pretty important things I want to get done soon:

• A cross-platform GUI version. Working on this now, about halfway done. Before this, individual battles are launched from command line.
• CPU time limits. I have CPU tracking in place and I know how I want to do the calibration / enforcement, just haven't finished it yet.
• Windows support. Nearly everything should compile/run fine on Windows, including all the libraries I'm using. The main blocker is I don't have Windows. Now that I know I won't be flushing this down the toilet, I may just cough up the dough to buy a copy of Windows for this project.

Hoping to have it up on GitHub / new web site / some new YouTube vids soon. :-)

Unless it gets really complicated, I can try to get the Windows version working. (I use Linux, but have a copy of Windows). I'm pretty busy for the next few days, but I should be able to work on it starting this weekend. Also where can I download the source?

Hey thanks... It's not anywhere yet. :-) Gearing up now for a first release, probably around this weekend. I'd be curious to hear how it goes, but it would be a bit more than just a simple compile. For a fully functional binary release that supports un/packaging bots, I need to replace my use of the mkdir and tar Unix commands. You'd also need to build SFML 2.0 from source because it's not officially released yet.

And of course I need a permanent solution for future versions, too. My main concern is whether I need Visual Studio, or if I can do it with free tools like g++ as I use on Mac/Linux.

Windows has MingW you could use, which is a gnu compiler, meaning using it would likely be more compatible then using VS. However you can get the express edition of VS for free (which has 32 bit c/c++ compiler). It even has an IDE.. which actually I think you 'have' to use, at least for building.

Great, thanks for the info! At a glance, MinGW looks like exactly what I'd want, and I also didn't know about Visual Studio Express.

Ok, finally released BerryBots v1.0.0: BerryBots.com. Right now everything's launched from the command line but the full GUI/menu version is also coming along well. I won't be pimping it on the RoboWiki too much because that just feels dirty, and I don't particularly expect to convert any Robocoders, but do let me know what you think if you check it out! Cheers,

Time for a BerryBot rumble!

For now I'd be happy just to hear that anyone else has actually run it on their computer. :-) If we get a bunch of people writing bots and we find ourselves in dire need of a Rumble, that would be a good problem to have!

You've got me wondering if I oughtn't just scrap my plan for a new Robocode bot and dive into BerryBots. I already did some graphs today what would become Maximum Escaoe Angle for BerryBots. The fact that torpedoes end at a definite coordinate means that it'd be more like Maximum Escape Region in Berrybots, at least for torpedo shots. They're elliptical in shape, with the minor axis parallel to the velocity vector at scan time. :)

After some looking at the API, it does seem like there'd be a lower barrier-of-entry for my high schoolers than Java!

Do BerryBots have a maximum velocity, or are they only constrained by the walls and the number of bits in the velocity variable?

I wouldn't totally jump ship just yet. :-) No, there's no max speed, but you lose some speed when you bounce off walls. On sample.massivebattle.lua some of the bots can get up to pretty high speeds. I originally thought I'd have wall damage to kind of keep you from just bouncing all around, but when it came time to add it I wondered if it really needed it. As it turns out, you could pretty easily add wall or ram damage in via the stage code, too.

I've thought a fair bit about MEA too, mostly for lasers. Because of the high speeds of lasers and ships I think something like the asin approximations we use (or used to use) in Robocode would be almost useless in BerryBots, and you'd have to either do it precisely or come up with a new formula, maybe with linear targeting as GF=0. Since ships can (with enough space) move faster than lasers, there are even cases where an enemy ship could get more than halfway around you before the laser/wave hits. So I'm not even sure exactly how the precise MEA simulations would go - the Robocode approach of always moving perpendicular to abs bearing at fire time is dependent on bullets moving faster than tanks, I think.

Yeah. Dodging strategies can get massively more complicated with this much maneuverability and the capability of going faster than the projectile.

It's basically 2D space combat with projectile weapons!

The MEA/MERegion is going to be the intersection of an expanding (in the time domain) circle from firing bot and a moving and expanding ellipse from the target bot. I haven't actually written out the math to see if there's a simple, clean solution to it, let alone done an iterative graph. My intuition is that it'll look like an ellipse blown up like a balloon on the far end and skewed linearly on the far end in the direction of the target's velocity at launch time.

If there's a clean solution, the solution to this is mathematically simpler than the Robocode case. (A caveat being that the projected region should be reflected by walls. Ouch.)

Though, I'd set a goal for myself of making the top 20 in the 1v1 Rumble by the end of the school year. I should keep my discipline on that commitment.

Haven't had a chance to look into coding anything for it thus far, but I tried building it from source under linux.

To get it to build I had to add "-ldl" to the linker flags and replace extern char *getcwd(char *buf, size_t size); with #include <unistd.h> in bbutil.cpp

There's an issue where sometimes the fonts/text is way too thick and just looks like blobs, but otherwise it seems to work nicely. I tried the precompiled one to check if the issue exists there, but that build depends on glew 1.6 when my system uses glew 1.8.

I haven't had a chance to try it out yet, but I think it would really help to have some sort of basic GUI launcher which enumerates the different battle type options and bots available (with brief descriptions), and then arranges the command line arguments with the options you've selected. Once you have that I'd suggest emailing the people at the Raspberry Pi foundation and they'll put it on their homepage blog - it would be a quick way to get a bunch of people interested and to get the word out. I also think it would be fine to have something on the Robowiki homepage saying something like "Is Robocode running slowly on your Raspberry Pi? Try out BerryBots <link>!"

The full GUI version is the next thing I'm working on. It has a battle launcher like Robocode, during battle it has ship (or team) names and health on the left that link to their individual output consoles. Right now I'm building on the Mac with XCode but wxWidgets should be portable to Linux and Windows. But I thought the Rpi version would stick with just the command line interface, actually. It just feels appropriately minimal and lightweight. Maybe I could make a totally different UI if the wxWidgets stuff doesn't port to the Rpi well.

About the homepage link, I'm hesitant to spam the RoboWiki with some new game of my own. ;) I posted in the Rpi Gaming forum, not sure how much that will get the word out.

I was thinking of a super-lightweight GUI being almost a command-builder which you then click 'execute' and it runs. That way it could teach you the command line layout while still being something that exposes all the options and allows Raspberry Pi/Linux beginners to access the full functionality without having to read scary man pages =)

I'm getting ~110 - 140 TPS with Walls vs. Crazy now that the render-when-minimised bug has been fixed. Hopefully a JIT will work on ARMv6 sometime soon.

Great! Now we just need to write a Java OpenGL graphics layer. :-)

In theory, any programming language capable of producing Java compatible byte-code can be used with the existing Robocode engine.

The trick would be for Robocode to support the language directly - like it does with the Java and the Jikes compiler. For me when I started this was a great benefit - no need to install a IDE or SDK - just run robocode and go.

For beginners a simpler language would be of benefit - what's would you recommend?

I'm kind of thinking that Lua might be a good language to target, because it's about as easy for beginners as it gets (and a JVM version of sorts does exist [1]).

One other note is, I think a lot of thought would need to be put into the robot API used for this proposed project. I'm of the opinion that the existing non-AdvancedRobot APIs do a less-than-ideal job at being simple to actually use even though the API is simple, and the AdvancedRobot API is kind of messy, in part due to how it's evolved over time (backwards compatibility and such).

The original API was born from the ACM competition and was designed on purpose to be hard-to-use.

Weird coordinate system, bots being disabled after 1000 API calls...

I personally think that reverse compatibility with normal robocode is non-ideal. We could have a non-pi version of course, but building it from the ground up to be simpler on a language like lua.

I'm a high school teacher in the U.S. with a programming class. I've done a lot more with Greenfoot this year than Robocode, but with Greenfoot and Robocode one has everything needed to keep kids motivated to write code. In that sense, Robocode has been great entertainment personally and a great boon professionally. Running a local rumble server a few years ago for the kids to compete in was tremendous fun for me and them!

It would be great to provide students with an in to Robocode utilizing a language with simpler syntax and less "don't worry about these big chunks of text for now... but you need them or it won't work" type provisos. Python or Lua would be neat choices. I've got to say I'd love to see any new language choices able to work within Robocode proper though... as has been done with .Net implementation.

Noticed this on the Raspberry Pi forums. Maybe there's hope for better Robocode on the Rpi after all? http://www.raspberrypi.org/phpBB3/viewtopic.php?p=150879