Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - MarvinMan

Pages: [1] 2 3 ... 17
Challenges / Re: Autonomous Combat League
« on: November 21, 2019, 08:05:31 pm »
That certainly looks impressive in the video. What version of the game was it built in? The damage per shot/rate of fire look unusually high compared to what I remember, though it could just be where it has 4 independent cannons.

Challenges / Re: Autonomous Combat League
« on: October 24, 2019, 10:28:20 pm »
Here's the monstrosity that evolved from the ACL tutorial bot. It still has its issues but it has served its purpose as a test bed (and become a convoluted mess of code in the process) and I have decided to take future development in a slightly different direction. The most likely thing to go wrong is the target acquisition system taking too long to identify a target.

Hammer: Lightweight (23 Parts) Anti-Armour Bot

This bot is best suited to facing heavily armoured opponents and relies on speed as its primary defence. Overall performance may be improved against many opponents by removing the armour to improve stability.


Tutorials & Guides [EN] / ACL example bot programming guide
« on: October 15, 2019, 08:56:43 pm »
The purpose of this guide is to explain the code required for a basic functioning combat bot suitable for participating in ACL. It is hoped that the ideas presented here will provide a foundation for others to use to build their first ACL entry. It is intended to take a step back from what may seem an overwhelming wall of code seen in some ACL bots and provide solutions to issues that may be obvious to experienced ACL participants but potentially present a challenege to those who have yet to experience the joys of trying to make a bot reverse out of a corner. This guide is suitable for anyone who is familiar with the basics of Rawbots. A blueprint of the bot is provided at the end of this guide.

1: Drive forwards
The first thing out bot needs to do is drive forwards until it sees a wall to avoid or an enemy to pursue. It is customary for ACL bots to use the 'X' key to enable weapons and movement. In this case the forward drive signal is a fixed value provided by a toggle. This bot is relatively slow to prevent it flipping when sudden changes are applied to the motors or navigating ramps. You may want to consider adding an integrator (or SLEW function in 0.16) to provide smoother acceleration, or code to make the bot drive faster in open spaces.

2 & 3: Don't crash into the wall
Now that our bot is moving, it is soon going to encounter a wall or ramp. The fundamental principle here is that hooks can 'see' terrain from a considerable distance, allowing bots to sense the world around them without crashing into it. Most bots use one distance sensor on each side, normally pointed roughly towards the front corners of the bot. When our bot sees a wall in its way we want it to steer away from it. Most designs will cause the bot to steer away from the side that has detected an obstacle. However, this can cause an issue when the bot is driving straight into a corner and can see a wall on both sides, usually causing the bot to either stop completely or continue driving straight into the wall. There have been various attempts to handle this, including scripted reverse, turn, continue procedures and bots that can drive in both directions. In this simple example we avoid the problem by stopping forward motion and always turning left when an obstacle is encountered. This is simply implemented by reversing the left wheel direction whenever the hooks detect that the bot is close to a wall.

Ramps complicate the wall avoidance somewhat. Again, there are various approaches to handling this. This bot uses two hooks on each side stacked on top of each other for the sake of showing how it's done, but you can also use a single pair of hooks which are angled upwards enough that they can see up ramps far enough to not trigger the collision avoidance code. Stacked hooks have less complicated placement requirements, and can easily detect ramps by checking for a difference between the top and bottom hook.

4: Identify a target
All combat bots need a camera to be able to identify a target. One major challenge that ACL bot designers face is picking out a target from scattered debris. This bot uses the camera activity output as a simple filter to only latch a target into a multiplexer when the part count exceeds 5. It is good practice to use some form of memory (like the multiplexer latch) for the targeted part so that the bot can continue to track its target even if it can't see it. You will likely want to improve the filtering for example to only target moving parts, or dynamically modify the camera box to check the proximity of the detected parts. You may also want to allow the camera to rotate and scan across the battlefield when it doesn't have a valid target.

5: Drive towards the target
Most ACL bots will benefit from proximity to the target, either for direct laser attacks or improved plasma cannon accuracy. In this example the code is rather brutally simple: If the left wheel motor is closest to the target, turn left, else turn right. The only slight complication is a check for the proximeters to have a valid output (not 65535) as the SIGN operand has no zero output. This is a part of the code that you should improve in your own bots, for example using a controller for smoother transitions or to implement target leading.

6: Precision targeting
This is where our example bot starts to deviate from the majority of existing ACL bots in terms of both philosophy and implementation. The majority of bots have turrets armed with rapid-fire plasma cannons (the implementation of such in worthy of a guide of its own) intended to saturate the target with damage at all ranges, whereas this bot has a fixed high-power cannon designed to one-hit nearly all parts. As such, every shot ideally needs to be on-target and the projectiles are faster and less affected by gravity.

To facilitate this, when the bot detects it is nearly pointing towards its target (the left and right proximity values are within +/-0.1) the camera switches from its wide scanning mode to a narrow beam looking along the barrel of the cannon.

7: Fire at the target
When the focused camera detects a part that is close to the part it is currently tracking a fire signal is sent to the cannon.

8: Only fire when fully charged
The philosophy of this bot is to detach any part it hits, for which it needs a fully charged cap. Additionally, undercharged shots are unlikely to be on-target as the projectile moves slower. To avoid this, an integrator is used as a timer which gates the fire signal to the cannon. When the cannon fires, the timer is reset and further shots are blocked until the counter finishes.

The bot as presented here weighs in at 20 parts, qualifying it for the lightweight (25 part) ACL class. However there are still mechanical improvements to be made, such as adding armour and removing unnecessary parts. Look out for the improved version in the ACL thread soon to see how this basic platform evolved into a (hopefully) competitive ACL contender.


Challenges / Re: Autonomous Combat League
« on: April 01, 2019, 08:22:30 pm »
Interesting idea.

The fixed camera seems to have same trouble finding targets compared to turret bots, but once it gets up close it is very effective. The low profile seems to make it difficult for most other bots to hit, and the cannon placement is almost guaranteed to cause crippling chassis/internal damage.

Development Logs / Re: The Development Road map
« on: March 30, 2019, 12:18:47 pm »
Once we have the ability to store code in re-usable blocks, it would be relatively simple to include a library of example functions that new players can use and learn from. Combined with a set of blueprints of archetypal bots, this would provide a good platform to get new players started and provide shortcuts for more general use.

Development Logs / Marvins view on the grand plan
« on: March 29, 2019, 09:07:25 pm »
The current state of Rawbots:
The Rawbots we have today is largely stable (remarkably so for something claiming to be pre-alpha), and numerous bugfixes and quality-of-life improvements have been made by the dev team for 0.15/0.16. The bot building and programming system is pretty solid, as evidenced by the creations on display in the various workshop and ACL threads. In other words, you can build nearly anything, but there isn't really any inherent motivation to, which has to be supplied by the players creative urges or community challenges.

The code contains several parts, ranging from the relatively straightforward but tedious to fully implement, through to parts presumably intended to have complex functions but only exist as a name and a model. Making these usable is likely to be part of the first stages of development as a reasonably safe addition of content we've been denied all these years.

Where to next?
The Rawbots universe is fairly dull, populated by a scattering of barren planets or whatever blocky structure the player cares to build suspended in an infinite void. On the structures front, there are plans to re-add the pillars and platforms seen in earlier versions, suitably scaled for compatibility with the smaller terrain hexes found in the current version. Also to be added are an assortment of minerals, resources and asteroids, which will start to bring the world alive and lay the foundations for an energy economy and motivation for exploration. While these would likely be inert statically generated features at first, developments could include random spawning, regeneration of resources, mining/harvesting and increased variety.

Longer term:
Cupid has done a pretty good job of outlining how gameplay driven by an energy/materials economy would work, so I'll just add a few paints here. While getting to this point is unlikely to require a complete overhaul of the game, significant changes will be required, and it would be best for us to understand the ultimate objectives now, rather than starting out without a clear picture and finding we've made some feature far more awkward to add than it otherwise could have been. In my opinion, the end game should provide a reason to build, automate and explore a dynamic universe, while allowing room for creativity for the sake of creativity at all stages of progression. Populating the world with NPC bots could be cool and really help bring the universe to life, but risks changing the character of the game, especially if things get too combat-heavy and it ends up resembling a base-building/tower defence game.

Parallel goals:
In addition to ongoing bugfixes, and the developments listed above, there should be gradual bot-building focused additions. These would include original new parts, new operands, building/programming aids, user friendliness/UI efficiency improvements, etc. As mentioned previously, there are potential changes to the underlying platform/physics engine, but I'll keep this post limited to user-facing changes for now.

Robotics / Re: Things you've built/invented/programmed (or want to)
« on: February 07, 2019, 07:05:21 pm »
Cool. I do electronic design professionally, and everyone I know considers anything RF to be a dark art.

Assembly language programming is getting to be a bit of an arkane ability these days, but it's certainly a good way to learn the intricacies of a particular processor, and useful for generating precise timings.

Challenges / Re: Autonomous Combat League
« on: January 27, 2019, 05:43:35 pm »
Things are even quieter than normal around here these days, but there are still a couple of us around.

Shame to hear the forums might be disappearing again, but I suppose it's hard to justify paying for the hosting when there are usually months between posts.

Screenshots & Videos / Re: Marvins Creations
« on: September 28, 2018, 07:51:46 am »
Interesting idea. I've not come across any obvious mechanical integrity problems with the props I've been testing, but I assume offsetting the fins is beneficial because it counters some of the stretch in the arcs, letting them effectively move to their optimal position under load/at speed.

Can hypercubes be used for de-stressing any structure? For example a string of continuums bent into a loop being turned into a stable structure that won't spring back when broken.

Screenshots & Videos / Re: Marvins Creations
« on: September 27, 2018, 09:24:16 pm »
I had noticed the graphs were broken when I uploaded them. I had hoped that google docs would make the spreadsheets more accessible than uploading them to dropbox.

When I started I wasn't particularly planning on publishing the data, so the labelling reflects my aversion to unnecessary typing. On the static results W is rotational speed of the prop, T is torque, and F is forward thrust (because T was already taken by torque). F/T gives a sort of measure of efficiency. On the second sheet, V is airspeed.

As torque and rotational speed are pretty constant at all airspeeds using variable pitch to control speed is probably better, but would need more work to characterise the pitch needed for peak thrust and zero thrust across the full speed range, especially if you did want to increase prop speed once in the air to take advantage of the improved airflow over the wings.

It appears that most of the energy input goes into just rotating the fins for no gain, so larger props allow more thrust/speed from a given rotational speed. The large props I tested using a cross piece as the hub were the best of the non-offset designs tested. Assuming it had enough thrust to get off the ground when retracted, a prop with pistons to increase its diameter might work well for efficient cruising or maximising top speed. I imagine such a design would make the handling of the plane awful, but it would be very fast.

Airspeed test rig.

Static thrust rig.

Screenshots & Videos / Re: Marvins Creations
« on: September 26, 2018, 10:55:05 pm »
Propeller infodump

Propellers in Rawbots are weird. The high torque they require and their dependence on airspeed make them ideal for quadrotors, but very tricky for planes. I was looking for a better design to power my planes, so I've characterised several different configurations to try to find out what works best. I've put the results in a couple of spreadsheets.

Static results

The first set of tests were for static thrust against torque, measured by balancing the thrust against a jet. The offset elbow type is the one seen fitted to my propeller plane above, and turns out to be the best fixed-pitch design over much of the range tested. Logically, a faster spinning, lower pitch prop should require less torque to provide the same thrust, however this only appears to be accurate at the lowest power levels. In general, a 45 degree pitch works pretty well. For best performance, use the largest diameter prop you can, and offset the fins slightly, like the offset elbow design.


Optimising the pitch over a range of airspeeds is where things get really weird. With a fixed 45 degree pitch and constant torque, the rotational speed only changes by 12% from stationary to a forward speed of 70 while the trust decreases linearly. This suggests that most of the torque requirement goes into just spinning the prop. When the pitch is optimised at each speed, the thrust shows more of a 1/x decay with airspeed, enabling much higher aircraft speeds to be attained (to the point where the wheeled test platform used for these tests reached escape velocity). Interestingly, the rotational speed of the prop stays largely constant throughout the test. For most sensible speeds, the pitch can be mapped linearly to forward speed.

Overall, it's probably better to just use a lightweight fixed-pitch prop optimised for lower speeds, but higher pitches will be needed to go fast.

General Discussion / Re: Is the development still being rebooted?
« on: July 02, 2018, 08:46:36 am »

The only thing I've seen is this:, although it doesn't exactly seem official. I think there was meant to be some sort of announcement months ago, but obviously nothing appeared.

Introductions / Re: Im back too!
« on: June 10, 2018, 09:35:46 am »
Welcome back.

I don't know what the deal is with that new site, but it does at least offer a more legitimate source to download the game, and presumably gets a little more publicity too.

General Discussion / Re: Rawbots development restart discussion
« on: June 04, 2018, 08:05:25 am »
There is of course this thing that appeared recently:

Still only has the same version of the game we've had for years and a load of old videos, but someones bothered to put it up.

General Discussion / Re: Rawbots development restart discussion
« on: March 02, 2018, 04:51:48 pm »
Apparently gmail thinks Rawbots forum updates are spam.

Anyway, there are a few of us still here, and the domain name got renewed recently.

Pages: [1] 2 3 ... 17