Drones with a Mad Scientist

[Lyinginbedmon]

Lesson 0: What is a drone? [Below]
Lesson 1: Fundamentals [Below]
Lesson 2: Awareness
Lesson 3: Coding Philosophy

Case Study #1: Robert the Luggage Bot

• Part 1: Basic Operation
• Part 2: Adding Complexity

Lesson 0: What is a drone?

Drones have a fairly broad definition, but critically they are almost always operated by complex expressions in an expression 2 chip, and often function autonomously to some extent. They are also sometimes referred to plainly as "bots".

For example:

An automated turret that hovers with applyForce and targets any NPCs it finds with entity discovery
A chatbot that stays where it lands and tells the owner things about what they're looking at whenever the owner asks it to in the chat
A contraption that hovers around the map looking for barrels and gathers them at the spawn point when it does

All three could be considered "drones", because they all use complex expressions to do different things.

• The turret needs timers to keep itself hovering, and it needs to sort through it's targets and determine which ones to attack, then how to point it's weaponry at them and do so. If it uses a turret, it needs to know only to fire when the turret is actually pointed at it's target, to minimise false shots and shooting the wrong things (Like the owner)
• The contraption has motion, barrel discovery, grabbing hold of them, and getting to the spawn point to consider.
• The chatbot needs to know if the owner has asked something of it and then exactly what to do from what they've asked.

One of the easiest ways of telling if something is a drone is from looking at it's expression.

If humans can be considered as large tubular filters that search for food to filter, then a drone's expression is often an intricate arrangement of three fundamental features: If functions, flipswitch variables, and timers.

These are also known as the fundamentals.

Lesson 1: Fundamentals

When you're making something complex, you need a selection of variables and functions to handle whatever you think is going to come up for it.

The three most important things for a drone are:

• If functions
• Flipswitch variables
• Timers

In that order.

If Functions
Simply put, an If function checks to see if something is true, and if it is does something. If the question is false, you can add elseif to ask something else immediately or else to do something immediately.

If functions are important because they allow your drone to ask if it should do something, and in larger codes they allow it to change parts of itself when necessary. This may mean that, if the drone is under water, it should increase it's altitude, or if you last told it to attack the nearest NPC, it should find it and move in for the kill.

If functions are written in the form of "if(Query){Do stuff}".

For example:

if(first()){E = entity(),O = owner()}

In this example, the Query is "first()" which returns true only when the chip is first spawned, and the Stuff is that variable E is the chip itself and variable O is the owner of the chip.

Flipswitch Variables
Flipswitches are very handy, because they allow you to turn parts of code on and off, reducing lag and stopping parts from interfering with eachother when they don't need to be.

Flipswitches are used in the form of If statements that use a specific variable as their query. When that variable is true (Usually by equalling 1), the statement turns on and does it's job. When that variable is false (Usually by equalling 0), it turns off entirely. The chip doesn't go past that initial query, so the statement produces virtually no lag beyond checking if it should turn on.

For example:

if(ResetAlt){Alt = 200,ResetAlt = 0}

In this example, ResetAlt is the flipswitch variable. When ResetAlt is made to be 1, the expression sets the Alt variable to 200 (Causing the drone to rise or lower to meet 200 altitude, assuming it's a flying contraption). Once it's finished, ResetAlt becomes 0, so the if statement turns off.

Remember: When using flipswitches, you need to put the variables in the @persist lines at the top of your code. Otherwise, they'll just reset to 0 at the end of each execution, becoming more like an untoggled button than a flipswitch. In larger codes, this means you'll probably end up with a dozen or so such variables, so don't be afraid to add additional @persist lines to clear them up.

Timers
Timers allow the code to run without changes in input after it's first spawned. This is especially useful for having it do something gradually, like moving a hydraulic so it doesn't break what's at the other end, or just repeatedly, like checking it's altitude or running through all the entries of an array.

Timers are written timer(S,N) where S is the name of the individual timer and N is the interval of milliseconds it triggers after (1000 milliseconds per second). You can also shut them off by using stoptimer(S), much like an interval. Important to remember is that timers, unless turned off, trigger every interval, not just once.

The reason timers are better for drones than simple intervals is that you can use the function clk(S) to have parts of code activate only when a certain timer triggers. As a consequence, you can have multiple timers in the same code with different times and have different things happen at all of them.

For example:

timer("light",1000)
timer("hop",750)
 
if(clk("light")){Light = !Light}
if(clk("hop")){Hop = !Hop}

Here, we have If functions, Flipswitch variables, and timers to achieve a relatively simple effect. Every 750 milliseconds, or 3/4 of a second, Hop switches on or off. Then, every 1000 milliseconds, or every second, Light toggles as well.

Similar to clk(S) is chatClk and tickClk, which trigger when the expression is activated by the chat from runOnChat(1) and server ticks from runOnTick(1), respectively.

Remember: Occasionally, you need to have a few things happen at the same time from the same timer, and occasionally those same things are conditionals, like If functions. In which case, it's often better to place them all under the same If functions that triggers with the interval, rather than add "& clk(S)" to them each.

[bluedragon11200]

Wow nice lesson, its gonna help me allot with e2.
Currently working on a laser jump mini game ( third e2 project) with e2 hopefully i wont need external timer chips to do it.
After that Ill hopefully will be able to finish my other drone project

edit= if you need me to delete my post for more space and to organize better let me know :P ( don't want to hinder a great tutorial like this one)

[Tasuit]

Very good tutorial so far, didnt really learn anything i did not know, but i am sure other people will

[eduardo]

i heart lying in bed

[Lyinginbedmon]

Lesson 2: Awareness
Some of the most basic things a drone can do are point at something, shoot something, move something, etc. But in order to do anything to anything, it needs to actually be aware of it.

There's a lot of things you can do with awareness in a drone, but let's cover how it can be made aware of them:

• Entity discovery
• Entity functions
• Rangers
• Water sensors

Entity Discovery
Entity discovery has a wide selection of functions, but what it basically does is look for entities in a specific area or finds all entities with a specific characteristic.

For example, you can use findByClass(S) to find all entities on the map of a specific class, like "prop_physics" to find all props. You could also use findInSphere(V,N) to find all the entities in a sphere region around the vector.

What you always need to do with entity discovery is filter and time. If you want to do anything intricate with the entities you also need to use Variable = findToArray() once the search and filtering is finished.

Filtering happens both before and after the actual find event. Before the find event, you can use the blacklist and whitelist functions (findAllow, findInclude, findExclude, findDisallow, and findClear) to pick and choose what entities or kinds of entities etc. the event should pick up on.

After the find event, you can use the findClip functions to do more specific things, depending on what you ran the find event for. You may run one find even for looking for nearby players and another for finding explosive barrels, for example.

Time comes in when you're using entity discovery functions repeatedly. They are very taxing on the server and as such already have two functions to tell you how often they can be used: findUpdateRate and findPlayerUpdateRate. The reason there are two is because individual players can only run find events every so often, and then chips themselves can only run them so often too.

One simple way of moderating a chip's find events is a flipswitch, like so:

if(Flip){
 timer("chip",findUpdateRate())
 timer("player",findPlayerUpdateRate())
 
 if(clk("chip")|clk("player")){Mark++}
 if(Mark == 2){Flip = !Flip}}

For this code, you would make Flip into a positive value after running each find event, and have finding turn off unless Flip is false (Using if(!Flip){#search} for example).

Entity Functions
The entity functions are predominantly used to find out information about entities (Which constitute almost everything in Gmod, from NPCs and props, to players and some map elements), two of the simplest are entity() for the chip itself and owner() for the chip's owner. Both return the relevant entity.

Using the chip, you can discern where it is against where it should be, and from there calculate how it should move. You can also determine whether it's underwater, on top of something, etc. E:pos() is one of the simplest ways of discerning information, by finding the entity's position in the XYZ space of the map.

If the chip is welded to something, or otherwise constrained, you can use E:getConstraints() to create an array of all the entities that it is constrained to. E:isWeldedto() is one of the most common methods, used often to find the entity that the chip is directly attached to.

Using the owner, you can get on-the-spot information straight from the owner, generally what they're looking at. E:aimEntity() for example gets the entity that the owner is personally pointing at, where you can also use E:aimPos() to get the co-ordinates of where they're looking at.

If you get a little more intricate, you can use the owner's aimEntity to build arrays and such of many entities for information.

You can use E:owner() to get the player that owns another entity. If you add in the built-in ranger you can use the entity's vectors to "pinball" around at other entities. If you find a vehicle, you can use E:driver() and E:passenger() to find who's inside it.

A recent drone I started working on even uses entity discovery to find the highest and lowest entity ID (E:id(), each one unique to a single entity) in a region, then runs through between them with entity(N) to build arrays of players, NPCs, and regular props.

Rangers
Fundamentally, rangers measure a distance between two points: The point where they start, and the point that is directly across from them, to a certain maximum distance.

Ordinary Wired Rangers can also output a variety of other information, such as the angle it hits and the entity ID of whatever it hits.

The built-in E2 ranger can do much the same, but can return the whole entity, and be made from anywhere in the map, such as from detected entities and simply in thin air. It can even be fed entities to ignore in it's beam, so you can effectively use it to see straight through things, like players, the world, and props to only detect NPCs.

With both, there is a "hit water" option (A checkbox with the wired ranger and rangerHitWater(N) with the E2 ranger) which will cause the beam to stop when it impacts water, so using it as an altitude marker would allow drones to hover over water rather than taking a swim along the seabed.

One of the most common uses of rangers is, understandably, to detect distance. Multiple rangers can make for an effective hazard avoidance system, by turning away from the direction outputting the lowest distance, for example.

Water Sensor
A fairly uncommon way of achieving awareness is the Wired Water Sensor and the E:isUnderWater() entity function. Uncommon because they only say whether something is underwater or not, so have very limited use on most maps.

Literally, they output a 1 or 0 (True or false) depending on whether the sensor or the entity is underwater in the map. Could be used in an automated submarine, or to tell a drone to go upwards to try and surface if it isn't already using a ranger to discern it's altitude.

Get Creative
As with many things Wiremod, combining existing features and using others in new ways allows you to achieve many things.

Remember the entity(N) drone I mentioned? Using that, you can have the drone gradually find out about everything on the map, as long as it finds something with a higher or lower entity ID than it has previously encountered, without needing entity discovery. That particular drone uses built-in rangers to navigate and detect new entities, combining hazard avoidance and entity awareness.

A lot of my more innovative awareness methods are based on avoiding the easy paths of entity discovery, and this is the case for a lot of aspects of drones for a lot of drone-builders.

[Lyinginbedmon]

Case Study #1: Robert the Luggage Bot

Let's start with something simple.

Here's version 1 of Robert.

This bot is designed to hover at a constant altitude from the ground beneath, remain fairly stable, and generally hold whatever you need it to hold gently and carefully.

So, in order to function he needs the following things:

• Altitude control - He needs to know how far away the ground beneath him is, and then rise or lower as needed.
• Angular control - He needs to stay stable, with at least one section that is flat for you to place your objects on.

So first, let's take a look at his chassis.



Here we see that he is chiefly composed of two props: A circular base to rest your objects on, with a nice border around it to keep them from falling out which is no collided with the base only.

On the underside we see that he has a simple entity marker to link to the border prop, a control expression chip, and a ranger to determine how far away from the ground he is.

On to the coding now.

@name Robert the Luggage Bot
@inputs Alt Border:entity
@persist Plate:entity
@persist Ang1:angle Ang2:angle Vec:vector
 
if(first()){
    Plate = entity():isWeldedTo()
}
 
runOnTick(1)
 
#Angular control
Ang1 = -Border:angles()*1000
Ang2 = -Plate:angles()*1000
 
Border:applyAngForce(Ang1 + $Ang1*5)
Plate:applyAngForce(Ang2 + $Ang2*5)
 
#Altitude control
Inc = 50 - Alt
Cur = Plate:massCenter():z()
 
Cen = Plate:massCenter():setZ(Cur + Inc)
 
#Motion control
Vec = (Cen - Plate:massCenter())*1000
 
Plate:applyForce(Vec + $Vec*5)

Remember: Adding # allows you to add comments to your code that will not interfere with it, which is useful for helping you and others understand what different parts do and what they are for.

Now let's look at what we already have for Robert on startup.

@name Robert the Luggage Bot
@inputs Alt Border:entity
@persist Plate:entity
@persist Ang1:angle Ang2:angle Vec:vector
 
if(first()){
    Plate = entity():isWeldedTo()
}
 
runOnTick(1)

The E2 is welded on spawning to the circular base, so we can easily find that as it uploads. Therefore, we need to persist Plate as an entity variable to ensure that the code remembers it. We're using an timer (runOnTick(1)) to have the chip execute whether it's inputs change or not (Important if the ranger distance exceeds it's max, otherwise it would realistically change constantly).

Moving on to the angular controls, we're just going to use a very simple applyAngForce code.

#Angular control
Ang1 = -Border:angles()*1000
Ang2 = -Plate:angles()*1000
 
Border:applyAngForce(Ang1 + $Ang1*5)
Plate:applyAngForce(Ang2 + $Ang2*5)

We simply take the E:angles() of the Plate and Border entities and negate them each with a fairly decent multiplier. This will keep the bot fairly stable in the air.

Next, the altitude control.

#Altitude control
Inc = 50 - Alt #Change of altitude needed
Cur = Plate:massCenter():z() #Current altitude
 
Cen = Plate:massCenter():setZ(Cur + Inc)

This code alters Cen, the vector variable that the bot uses for it's motion control, to meet a Z value that will theoretically be the correct 50 units from the ground that it wants. We don't need to persist Cen because it's worked out each time the chip runs and is used in Vec for the motion control (Which is persisted).

Lastly, the motion controls.

#Motion control
Vec = (Cen - Plate:massCenter())*1000
 
Plate:applyForce(Vec + $Vec*5)

Simple enough, applyForce (Using the traditional formula of Vector = (Destination - Location)*Multiplier) keeps the Plate entity in the air according to the Z value set by altitude control earlier, and similarly leaves it floating rather freely in place according to whatever way you whack it.

[thirty9th]

Very nice tutorials; I enjoyed both of them.

These are good for both total beginners to drones, and those who have a little experience but need help with finer points.

[Tasuit]

IMPRESSIVE!
Your the man!
very good tutorial, it tells you some wire knowledge, which you before had to figure out yourself! Been waiting for this!
Rep++ to you!

[Solece]

Hmm, very nice. I guess your finally getting to work instead of all talk now , although there is still alot of talk xD

[Neo Kabuto]

What's all that stuff in the backgrounds in the Robert photos? Your secret mad scientist lair?