This was enough to have bombs move, draw and be removed when it becomes inactive.

Dropping Bombs

We added a new function to Ememy called shoot(). In that function we generated a random number from one to two hundred. We then dropped a bomb every time that number was less than five (we tuned this small number to get a good rate of bomb drops). This meant that the enemy dropped a bomb at random intervals, to make it impossible for the player to anticipate.

This week we looked at GPS which stands for Global Positioning System. The idea behind GPS is based on time and the position of a network of satellites. The satellites have very accurate clocks and the satellite locations are known with great precision.

Each GPS satellite continuously transmits a radio signal containing the current time and data about its position. The time delay between when the satellite transmits a signal and the receiver receives it is proportional to the distance from the satellite to the receiver. A GPS receiver monitors multiple satellites and uses their locations and the time it takes for the signals to reach it to determine its location . At a minimum, four satellites must be in view of the receiver for it to get a location fix.

We used the Adafruit Ultimate GPS Breakout connected to an Arduino as our GPS receiver. It’s very easy to set up, all we did was install the Adafruit GPS library on our Arduino and this gave us a load of programmes to chose from. We used the parsing sketch which gave us Longitude, Latitude and our location in degrees which we used with google maps to show our location.

See you all again on the 23/Mar/19

Declan, Dave and Alaidh

]]>https://coderdojoathenry.org/2019/03/14/bodgers-gps/feed/0declanfoxExplorers Week 6 – Storytellinghttps://coderdojoathenry.org/2019/03/14/explorers-week-6-storytelling/
https://coderdojoathenry.org/2019/03/14/explorers-week-6-storytelling/#respondThu, 14 Mar 2019 07:33:09 +0000http://coderdojoathenry.org/?p=6535Continue reading →]]>We had a great day in Scratch Beginners on Saturday! We created a project in which the Sprites communicated with each other to tell some sort of a story or bad joke, Like I did!

Timing was very important, each sprite had to wait for the other sprite to have their say.

This will save a picture called foo in the folder you ran your script from.

OpenCV (Open source computer vision) is a library of programming functions mainly aimed at real-time computer vision. We tried a couple of scripts out, one from the Hackers group, thanks Kevin, that detects colours and another one that detects shapes, we will be looking at this much more in the next few sessions but next Saturday we will look at using an Arduino and a Raspberry Pi together.

This week we extended our colliders so that we could used them to prevent the player going off the edges of the screen. We used it to show how software design needs to evolve.

Colliders

Our colliders were designed to be connected to an object with three things:

A property x containing the x-coordinate of its location

A property y containing the y-coordinate of its location

A function hit() which was called if the attached collider touched another collider

Something to Connect To

We had colliders already attached to our:

Enemy

Bullets

but we didn’t have anything to attach to that could represent the side of the screen.

We created a new class called Static() with nothing more than the x, y and hit() that we needed so that we could connect a collider to it (stored in one more property – collider).

Screen Edges

We created a pair of these colliders positioned at the right and left-hand side of the screen. We made sure to add them to our list in check_colliders(). Nothing much happened. Why? Well, first, the Player didn’t have a collider, so we added one, liberally copying code from Enemy, which a minor change to the description argument.

Now we could see the contact occurring between the edge and the player, though nothing was stopping it moving yet.

Unintended Consequences

As often happens with code, this change had unexpected consequences; bullets were not firing properly any more. Why? Because the player now had a collider and the bullets were becoming inactive immediately because they were hitting that. The fix was to modify the Bullet’s hit() function to ignore hitting a collider with the description “player”.

Stopping the Player Moving

We now knew our player was hitting an edge, but another problem became apparent: we didn’t know which edge!

To properly stop the player and stop it moving too far, we really needed to know which side of the player the collider we’d hit was, but that information wasn’t available to us with the current design.

A couple of quick changes were necessary:

In Collider.touching(), instead of just passing the descriptors to the objects hit() functions, we changed it to pass the Collider itself.

In all the hit() functions, we had to made a small adjustment to account for the fact that we were now getting a Collider and not just a string.

With the extra information from the collider, were were able to determine how far the player should be allowed to move to and prevent it going further by setting the x value appropriately.

]]>https://coderdojoathenry.org/2019/03/05/creators-shootah-part-5-edges/feed/0cdathenryspaceship.pngHackers – How to Steer an Autonomous Wheeled Robot to Drive Towards a Detected Objecthttps://coderdojoathenry.org/2019/02/24/hackers-how-to-steer-an-autonomous-wheeled-robot-to-drive-towards-a-detected-object/
https://coderdojoathenry.org/2019/02/24/hackers-how-to-steer-an-autonomous-wheeled-robot-to-drive-towards-a-detected-object/#commentsSun, 24 Feb 2019 20:50:00 +0000http://coderdojoathenry.org/?p=6511Continue reading →]]>During the same session at which we figured out how to translate joystick movements into motor signals for a robot with two drive wheels (https://coderdojoathenry.org/2019/02/24/hackers-how-to-control-a-robots-wheel-motors-based-on-joystick-movements/), we moved on to figuring out how to control the motor so as to steer an autonomous robot towards an object of interest.

Again, we did a bunch of calculations on a whiteboard (see end of post), and I have re-drawn them for this post.

We have a robot with two wheels attached to motors, one on the left and one on the right

We have code to control the motors for the two wheels (which we call MotorM1 and MotorM2) with a value in the range -1 to 1, where 1 is full speed ahead, 0 is no movement, and -1 is full speed reverse

We have a camera mounted on the robot, facing directly ahead

We have code to get an image from the camera and can detect an object of interest, and find its centre (or centroid) within the image

The objective is:

If the object is in the middle of the image, robot should go straight ahead (M1=1, M2=1)

If the object is to the right, move forward-right (e.g. M1=1, M2=0.7)

Likewise, if the object is to the left of centre, move forward-left (e.g. M1=0.7, M2=1)

If the object is not found, we turn the robot around in a circle to search for it (M1=1, M2=-1)

The first three of these are illustrated below:

Our solution is to treat this as a variant of what we previously worked out before, where we had a joystick input, where the X direction of the joystick controls forward movement and its Y direction controls whether to move left or right. In this case, we are steering left/right while always moving forward. Therefore, X has a fixed value (X=1) and Y is a value that depends on the direction of the object of interest.

The equations we came up with are:

X = 1 (a fixed value)

Y = (W – HWid) * YMax / HWid

Then use X and Y to calculate the motor control values as before:

M1 = X + Y, constrained to being between -1 and +1

M2 = X – Y, constrained to being between -1 and +1

Here:

X is a fixed positive value: X=1 for full speed, or make it smaller to move forward more slowly

Y is calculated from the equation above

W is the distance of object’s centre from left edge of the image, in pixels

HWid is half the width of the image, in pixels (for example, for a basic VGA image, 640×480, HWid is 640/2 = 320)

YMax is a value approximately 0.5, but needs to be calibrated – it depends on how sharply you want your robot to steer towards the object

M1 is the control signal for Motor M1, in the range -1 (full reverse) to +1 (full forward)

M2 is the same for Motor M2

Constrained means: if the calculated value is less than -1, set it to -1; if it is greater than +1, set it to +1.

At our most recent session in the Hackers group in CoderDojo Athenry, we spent out time on practical mathematics, figuring out how, if we want to make a robot that is controlled by a person with a joystick, how exactly do we translate movements of the joystick to signals sent to the motors.

Our assumptions are:

We are controlling robot with 2 drive wheels, one on the left and one on the right, like the one shown in the photo above (which we made last year)

We assume that we have code to control the motors for the two wheels (which we call MotorM1 and MotorM2) with a value in the range -1 to 1, where 1 is full speed ahead, 0 is no movement, and -1 is full speed reverse

To make the robot turn, drive the motors M1 and M2 at different speeds

We assume that we have code to receive signals from the joystick, and get X and Y values in the range -1 to 1, as shown in the diagram below

Our approach was to think about what joystick positions (X and Y) should result in what robot movements (M1 and M2), and then see if we could come up a way of expressing M1 and M2 in terms of X and Y. We filled a whiteboard with satisfying diagrams and calculations; see the bottom of this post. I have re-dawn them for clarity below.

The resulting equations are quite simple:

M1 = X + Y, constrained to being between -1 and +1

M2 = X – Y, constrained to being between -1 and +1

Here:

M1 is the control signal for Motor M1, in the range -1 (full reverse) to +1 (full forward)

M2 is the same for Motor M2

X is the forward position of the joystick from -1 (full back) to +1 (full forward)

Y is the left/right position of the joystick from -1 (full left) to +1 (full right)

Constrained means: if the calculated value is less than -1, set it to -1; if it is greater than +1, set it to +1.

Here is the full set of joystick positions and motor movements that we considered, showing how the equations work:

Each motor needs two control signals in the range 0-255, one for forward and one for reverse, so we will need more code to convert our M1 and M2 to what is needed for the H-bridge, but that is a fairly easy job for a different day.