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.

Topics - MarvinMan

Pages: [1]
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 / Mini challenge: Extreme hill climb
« on: April 05, 2017, 11:12:57 pm »
Extreme hill climb mini challenge!

Here's a quick challenge while we wait for the new version of Rawbots to surface. The goal is simple: make it to the top of the ramp, complete the zero-G hairpin and safely get down again.

Easy mode: anything goes. Use jets for as much free propulsion and downforce as you want.
Hard mode: no active downforce. Only use fins for downforce, so you have to keep going or you'll drift off into space.
Extreme mode: none of the above. Show off some more exotic solutions to the problem.


Challenges / Planetary ACL
« on: December 07, 2016, 08:51:42 pm »
I've been thinking about where ACL can go next. Full 3D dog fighting in space would be cool, but represents a huge step change in difficulty and rules. I think that holding ACL matches on planets with a reduced rule set would make ground based combat more interesting and provide a smoother transition to art-to-air engagements. All the current ACL bots would still be viable, perhaps with some tweaks for longer range accuracy, so any bots built for the new format would have something to compete against immediately.

The rules could probably be cut back a lot, just keeping the parts limits and some restrictions on homing projectiles/suicide attacks. All types of ground, hover and flying bots would be allowed providing they stay within the gravitational field of the planet. Almost all types of weapons, including lasers, grenades, mines, missiles and plasma cannons are allowed, with some limitations on homing projectiles.

Overall, planetary ACL should be much faster and more dynamic, with less of the point-blank cannon spam that happens currently.

Any ideas/suggestions?

Screenshots & Videos / Marvins Creations
« on: November 30, 2016, 08:40:35 pm »
Twin rotor helicopter 'Gemini' version 1.0

This is my latest attempt at building a working helicopter. Previous iterations used a fully mechanical cyclic to overcome limitations in code speed. The result of this was a large assembly under each rotor and the helicopter was barely controllable when it ever managed to generate lift for long enough to get off of the ground.

This version is much more light weight and uses a software cyclic which works much better. The system to synchronise the interleaved twin rotors is also massively improved and completely prevents collisions even with asymmetrical loading on the two rotors. The result is a stable platform that replicates all the key functionality of a real helicopter.

It turns out that the tail isn't really necessary, and actually negatively impacts the performance when not flying forward. The bare V shaped rotor assembly would probably happily fly on its own.

C/T- Throttle: This sets the speed of rotation of the rotors, and should be set to full while the helicopter is in operation. The currently set operating speed is by no means optimal, but provides a satisfactory compromise between generating enough lift and not outpacing the cyclic control code.
G/H- Collective: Alters the pitch of all of the rotor blades to increase/decrease the amount of lift generated.
Y/I- Cyclic pitch
F/P- Cyclic roll: The cyclic control individually varies the pitch of each of the rotor blades over the course of each revolution. This causes one half of the rotor to generate more lift than the other, creating torque that alters the attitude of the helicopter.
D/U- Yaw: Acts as a rudder to change the heading of the helicopter by increasing the pitch of one rotor while decreasing the pitch of the other, creating an unbalance in the torque between the two rotors.


And here's what makes it tick. The two big blocks are the phase shifts and sine functions to calculate the correct angle for each blade. On the left are a couple of basic controllers to keep the helicopter roughly level, and the code going to the bottom of the screen is to sync the two rotors.

Close, but no cigar. Really, I'm just impressed that it managed to lift something so huge that far without falling out of the sky.

Challenges / Autonomous Racing League
« on: April 09, 2016, 08:59:36 pm »
Welcome to the Autonomous Racing League!

This thread is dedicated to battles races between autonomous bots in Rawbots. It is intended to be a fun and friendly competition between bots and bot builders while providing a bit of spectacle to the Rawbots Club community. Building and programming an autonomous bot requires a fairly high level of effort, so be respectful to your fellow Rawboticists and above all have fun!
Competition/Construction Rules (subject to significant change):
  • No damage causing weapons. Ramming and flipping is allowed, but remember this is ultimately a race.
  • Jets, propellers, mass drives and other thrust sources are banned, both for propulsion and downforce.
  • Bind a key to start/stop the drive, weapons and aiming systems (use ‘X’)
  • Link a ‘spare’ Continuum to the rest of the bot via code (the ‘highlight’ color input is a good way to do this) so that the Continuums can be connected together to start all the bots simultaneously. Make it obvious which Continuum is the ‘spare’ one.
  • No Hypercube/Hypercannon weapons (possibly subject to revision if someone can come up with a convincing reason to allow them)
  • Ensure your bots are capable of reliably driving up and down ramps without assistance.
  • All bots must at least try to remain in contact with the track floor. (Getting airtime coming off ramps is fine, constant hovering is not).
  • Bots must be able to fit on a standard terrain hex. (actual dimensions up for debate)
    • The entry must consist of a single blueprint
    • Bots should be bluprinted in the correct orientation to be placed on the start grid
  • Make note of any special conditions with using your bot (keep these to a minimum!)

  • Give your bot a name. It is much easier to refer to a bot called “Buzzcut” then “PressureLine’s bot with the laser saw.”
  • Choose a color. The ‘color_a’ of Floaters and ‘highlight’ of Continuums are good part choices for making your bot visually distinctive.
  • It is recommended to use a drive system that avoids unnecessary contact between bots to prevent a pile up right off the start line.

Creating Arenas:
  • Outer walls should be at least 2 hexes higher than the local track surface.
  • Ensure any switches or buttons are protected from the battle area to prevent accidental activation/deactivation.
  • Please note if the arena contains jumps or other more extreme obstacles where bots may flip.
  • Large amounts of grass can cause slowdowns, use it as a garnish only.
  • The start grid should be oriented the same way on all tracks to simplify placing bots on the grid
  • Bots cannot detect Lava or Ice separately from Earth/Metal. Use caution when placing these hexes in your arenas.

These are currently a draft set of rules. Please suggest any changes that you think would make races better.
Running races:
  • Download and use XFM v0.5, a mod that contains various fixes and rebalancing to make combat more interesting, as well as the addition of inverse trig functions (which will cause the game to crash if used on an version of Rawbots which does not have the functions availible)
  • Simply download the bots and the tracks, set up the bots on the grid and press Go!
  • Take pictures and videos, write battle reports and review competitors.

It is probably worth keeping this thread for entry announcements and results discussions. Please use the link coming soon for discussing the construction and programming of competing bots (feel free to debate the merits [or otherwise] of bots and tracks here though).

Blueprints / Dumping blueprints and save files
« on: March 13, 2016, 07:36:17 pm »
Cupid wanted to see some example combat bots, and it turns out my entire save folder is uploaded to dropbox, so I thought I'd share it here.


That is over 200MB of unsorted blueprints and maps including many of the combat bots. The folder includes most of the challenge maps and my entries, a few bots that others have shared on the forums, and likely a load of broken save files too. I've not removed any previous iterations or old versions of save files, so it should be possible to look through and see how a given bot was built.

I won't guarantee that any of the bots work properly, and most of them will be mapped to Dvorak keyboard.

If you have any questions, feel free to ask. I'll try to remember the answer, but some of this stuff goes back to the days of stardust.

Robotics / Things you've built/invented/programmed (or want to)
« on: March 10, 2016, 10:55:02 pm »
This is a place to share and discuss your own hardware and software projects.

Feel free to post or ask about anything vaguely related, from your first attempts at controlling servos to building your own terminator army.

It's good to see the mod is still around. Even if we don't have enough members to revive the automated arena yet, the mod includes several useful changes, particularly allowing longer arcs to be created.

If anyone's not used the mod before, I'd definitely recommend it, especially if you find yourself eternally sticking the wheels back onto your bots.

On the subject of further work on XFM, how hard would it be to remove the starry background on the lower graphics settings (or make the terrain not transparent)? For some reason the terrain becomes mare transparent the lower the graphics are set. I'd not really had an issue with it before, but I'm currently having to run on the lowest graphics setting to get anything resembling a playable framerate.

Pages: [1]