Recent Posts

Pages: [1] 2 3 ... 10
1
Challenges / Re: Autonomous Combat League
« Last post by Sleeping_Owl on December 10, 2019, 08:16:22 pm »
Courier: Middleweight, 48 parts

Deliver a grenade to opponent, run.




Blueprint: https://drive.google.com/open?id=1ayLhvlGRDulvFdk16Ejye9OpG61xvERJ
2
Challenges / Re: Autonomous Combat League
« Last post by Sleeping_Owl on November 30, 2019, 02:00:29 am »
Some Lasers: Middleweight, 48 parts

This laser bot was not designed, it happened. This was a chassis meant for another bot with lasers added on top as a test bench for short lasers.
It happened to be effective enough for its own ACL entry.




Blueprint: https://drive.google.com/file/d/1lZoJzHZWrjHs_Ah-H16SVtnZ91FhBA1-
3
Challenges / Re: Autonomous Combat League
« Last post by PressureLine on November 24, 2019, 08:49:07 am »
New Lightweight competitor!

Melty



Weighing in at 25 parts, Melty is a lightweight Fist Melee bot capable of tracking and engaging ground based opponents only.

Get Melty here.
4
Challenges / Re: Autonomous Combat League
« Last post by Sleeping_Owl on November 21, 2019, 08:48:11 pm »
Bot was started very long time ago. Video is from 0.1.6.
By ACL standards it has quite low rate of fire and each cannon fires only once per full circle. This was not really intended, just the fastest rotation that allows reliable aiming, but works quite well.
The initial idea was just rotating armor: spreads incoming damage over more parts, pushes ramming bots to the side, could mess with aim.
5
Challenges / Re: Autonomous Combat League
« Last post by MarvinMan 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.
6
Challenges / Re: Autonomous Combat League
« Last post by Sleeping_Owl on November 18, 2019, 02:02:03 am »
Carousel: Middleweght, 49 parts.
Plasma shooter that spreads damage over its rotating armor. Plasma cannons are mounted on the same rotating part, so no need to aim just shoot when a cannon passes by.




https://drive.google.com/file/d/1Lu4lX2BsLanML-hBq1xmslIj2kFK1X8y
7
Challenges / Re: Autonomous Combat League
« Last post by MarvinMan 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.

Blueprint: https://www.dropbox.com/s/pv91pt48btimslg/bp_hammer?dl=0
8
Tutorials & Guides [EN] / ACL example bot programming guide
« Last post by MarvinMan 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.

Blueprint: https://www.dropbox.com/s/h7zak28hlrvxue6/bp_simple1?dl=0
9
Development Logs / New Devlog 6/4/2019
« Last post by cupid_the_conqueror on June 05, 2019, 02:41:34 am »
Hello everybody, I know its been a while since the last devlog, but I don't want to pull a Rozgo and leave you all in the dark.

I have good news, and I have bad news.  So as per tradition, I will start with the good news.

The good news is, development isn't dead. We've recently taken on a new team member, and our understanding of the rawbots source code grows every week - if ever slowly -

The bad news is, 1.6 is a long waaays off. We realized while working on the project that we really need to have a fundamental understanding of HOW the source code works going forward, and I won't put icing on the cake here - none of us really have the professional experience or education that the original development team had. In order to understand how to do fundamental improvements not just to performance, but also to game play mechanics, we have to learn how everything is hooked up and what everything does. For example, Z26 has been learning how to use the debug tools the devs left baked in to the source.

I really need to emphasize this ; Nothing is documented. Period. We may have gotten the source, and some of the older .git data, but we don't have internal notes or documentation. So we have the long and arduous  task  of creating our own.


Now for even more bad news. Some of the development team is busy with real life happenings. I know myself, I have quite alot on my plate. I recently evicted a destructive room mate, have become a property manager, and have a host of finical issues years of neglect have caused. I have books on C# net 7, Unity 2018 , Java and java script, python, Design patterns for object oriented code... ect ect.. but they will be gathering dust in my library until things settle down.

But I can promise you from the bottom of my heart, we will not go dark and give up. We will make progress over time (heck, the battle of wesnoth was worked on on/off for what.. 12 years?)

we have a lot to do , and a lot to learn. And if in the future the source code goes fully open, we will still be here doing our work.



as per pressureline - "stay calm and build rawbots"
10
Challenges / Re: Autonomous Combat League
« Last post by MarvinMan 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.
Pages: [1] 2 3 ... 10