Category Archives: Work

Robotics: Post 2

Hello, reader.

So today is a day after I was in class, but now that I’ve got some rest and have taken care of the other chores around the house, it’s about time I get to writing again about how my Robotics class has gone.

Yesterday afternoon, me, Urooj and Braxton attended our Robotics class after having had a reading assignment along with written summaries of the various vehicles described in our class book. If I haven’t talked about the book in my first post, I’ll take time to edit it in so you can check it out if you want.

Anyways, similarly to how our first class went, we had another lab to complete. This time around, we were tasked with manually attaching light sensors to a robot through any input between 0-8 on the component that downloads and stores the C code from the computer we write it on. I will edit this blog post within a week to take some photos of the device and show and explain in better detail as to how we hook everything up.

So, we get the light sensors plugged in, and our Professor states that we need to surround the light sensors with a straw, black tape surrounding the straw to keep light from the sides of the sensors from throwing them off too much, and then to attach the light sensors using double sided tape about 45 degrees away from the middlemost point of the circular iRobot-create. So, imagine a circle with a line going from the center of the circle to the topmost portion of the circle, then two lines slightly apart from it going off in either direction.

The light sensors, positioned in such a way, would be able to more accurately track light levels along with the minor modifications we made to it. The straw and tape combo made for a useful casing around the sensors themselves.

So, now we have the iRobot-create set up with light sensors attached through the device that contains the code and is simultaneously connected to the iRobot itself. This provides the iRobot with the ability to intelligently sense varying light levels. Now, we begin to write the code.

I’m afraid I cannot go into super in-depth detail about it now – however, I will just go over the overall experience of programming the robot in C. It was up to us to set up the core components of the code including any variables we needed to use to keep track of things and whileif statements to cause the robot to move. We did this rather quickly.

Initially we kind of screwed up and it just kept going forward. This was because we had it constantly run a command to make the iRobot-create move forward instead of running the other nested if loops. So, we removed this command and made an if loop for it.

You may be wondering, “If loops, while loops, schmile loops. I’m not understanding what you are talking about.” If so, that is completely fine. I will try and explain the outline of our code here onward.

The General Design

So, the code begins to run. It has the variables for detecting the light levels accounted for and it knows which ports the light sensors are plugged into. Therefore, we can gain a sense of how bright it is in front of the robot and a little to its sides. After we got this done, we started setting up the iRobot to move forward on its own. We fumbled with this at first, but then realized why it would only constantly move forward – slightly flawed coding.

After we fixed this small issue, we moved on to creating the while loop, which contained all the if loops; it also had the ability to cancel out of the while loop once certain criteria were fulfilled. The criteria we chose was for the iRobot to stop moving once the lightbulb placed in front of it got too bright for its liking. We enabled it to do this by measuring how bright the light was on each light sensor – if it detected light too far to the right, the left motor would speed up and correct its trajectory; this was the same except vice versa regarding the right-side motor and left side sensor.

Once we figured out how to get it to work, it ran like a beaut’. It ran fast at first trying to find the light source. Then, once the light source was in range, it made sure to correct for its direction and face the light while approaching it. This finally culminated in it stopping within about a foot or so of the bulb. Had we left out the line of code to stop the iRobot, it would have simply kept on going forward, even possibly damaging the light bulb or itself.

Many seemingly trivial things in programming can cause big issues, so it’s all about caring about what you do and taking it easy so you don’t get frustrated and give up. You never want to do a rush job when it comes to coding as every day programming becomes increasingly ingrained into our lives. Anyways, I do hope you enjoyed reading about our day working with the robot. While we haven’t completed the last bits of programming needed for the other variations of what the bot should do, we will be completely capable of tackling it come next week. Have a nice rest of your day, and I will see you around for next time!

From the blog CS@Worcester – Sean Raleigh's CS Blog by sraleigh62 and used with permission of the author. All other rights reserved by the author.

Computer Construction, Deconstruction, and Architecture: Day 2

My second day of Computer Construction, Deconstruction, and Architecture (from hereforth I shall call CCDA) went very well. I’m with my friend Emmanuel Braxton in that class. Another person who’s name I do not remember but will put here in a future edit joined me and Braxtons group to discuss various words and their meanings in relation to what we would be discussing further in class.

Firstly, we spoke of abstraction. Abstraction as our group defined it is a base representation of somethings attributes. For example, in the coding language Java, a class could be considered an abstraction of something real. If you were designing a program that would take into account the various persons in a classroom, the Person class would be an abstraction of a real life person.

Afterwards, we spoke of encapsulation. Encapsulation in Java programming and other programming languages like it, is a term that describes the process of creating a user interface that gives the user the ability to modify some variables using public methods. For example, designing a fake atm, you could have a class for Accounts and a class for System (which would contain the code that would emulate using an atm terminal). The user cannot modify variables from the Accounts class as they are forced to go through the encapsulated System class.

We say the System class is encapsulated because it is designed to disable the users capability of accessing all of its variables outside of using methods the programmer designed for the user to access them.

Anyways, while my description of encapsulation may not be fully correct or perhaps as well written as it could be, that is what our group came to the conclusion with.

Now, we will move onto our next subject, which is Inheritance. Inheritance is easier to describe than encapsulation, at least in my personal opinion. Inheritance describes the way a class gets variables and methods through a class its senior. We describe the senior class as a Parent and the class that inherits from it its Child, or subclass.

The parent class is usually abstract — for example, a Shape class in java would be abstract as we can’t really just create a new shape; rather, classes like Circle and Square and Triangle all have a method, getArea(), which is inherited from the Shape class. Why? Because for all classes that inherit from Shape, they should be able to calculate their area in each of their own ways.

Now, we will move on to Objects. Objects are created from the Constructor method of a Class. Let us say that you have a Player class for a video game. If it is a four player game, you do not write code for four other players; rather, you create four Player Objects within a Main Class (when I say main class I mean the class that is used to run the code). These Player Objects each have their own copies of the Variables and Methods programmed into their classes.

To finish this all up, we have Abstract classes and we have Interfaces. What makes these two pieces of programming similar? They each are parents to subclasses — they have classes that extends (inherits from the abstract class) or implements (inherits from the interface) either of the two.

Now, what causes the two to differ? While they have that one similarity, there is something Abstract classes have that Interfaces do not — Abstract classes can have variables its subclasses can inherit, while interfaces only describe what methods a class that implements it must take into account for.

This concludes what we talked about in our group for CCDA. I hope my writing was enjoyable enough to read, and I wish you a great rest of your day.

From the blog CS@Worcester – Sean Raleigh's CS Blog by sraleigh62 and used with permission of the author. All other rights reserved by the author.

Robotics, Day One

Hello again, my dear reader.

Today is the day me and my friends and fellow peers Urooj Haider and Emmanuel Braxton tackle our first small Robotics assignment. It is a Lab which will get us acquainted with the basics of programming a Robot through KISS (KIPR’s Instructional Software System) and running a simulation through it as well.

Currently, Urooj is writing for her own blog while Emmanuel goes and grabs a circular Robot made compatible with the programming application. I am downloading the application on my Ubuntu operating system (dual loaded with Windows 10 which was the original system on the computer.) while also getting Wine (a program used to help Ubuntu run Windows programs) set up as well.

Braxton got back now, so we are putting the bot together. Once it is together we will then begin to program some basic instructions for the bot to follow, and we hope that it will work smoothly and quickly. Oh! And I forgot to mention; Braxton ran the sim of the robot in the program and it had crossed a white line (I’m assuming representing a wall) and showed that its bumpers could tell when it had hit something.

So, we just now completed setting up the robot. Here is an image that I took using my Galaxy S7 Edge phone:


The device connects via a circular cable, which goes into the Botball device. Both the bot and the device itself can be charged via a much smaller in diameter circular power cord. Along with the ability to connect to each other and to connect to a power source for charging, it also has a usb cable that, from the Botball device, connects the bot all the way to Braxtons laptop.

So, we just ran the program through the Botball connected to the bot itself. The Botball store the program for immediate use simply by clicking a run button to begin running the code. Connected to the bot, it feeds it the instructions we gave it: Move forward for approx. ten seconds and then wait ten seconds, after which it would shut down (the program.) It was incredibly fascinating to see it come to life in the push of a button!

Right now, I’m watching on as Urooj and Braxton talk between each other as Braxton begins programming for use with the bot. There are methods we can use for the robot which can do the following things (and more): Move forward or backward, rotate on the spot clockwise or counter-clockwise, pause to wait, pause awaiting user input, etc.

With complex enough coding, one could make up games to play with the bot! One game I imagine is in which the robot rotates constantly and you have to try and guess where it will land. It randomly calculates how long it will rotate for and whoever gets the closest guess, wins!

What is Braxton programming, you may ask? Well, he’s attempting to program in a way for the robot to check and give the distance it traveled over the time it was used. There is a specific method for getting and setting travel time.

We are working through some of the kinks of working with C programming. It for sure is not completely straightforward nor easy to diagnose when issues occur, but it is completely doable. We are attempting to get it to move a distance, tell when its moved a certain amount,  and then stop it from moving past that amount of distance.

I have completed my version of the programming which worked out flawlessly in the simulation, and now we are also trying out Braxtons code too. His code worked and only went over by 35mm.


Now both of our code is nearly perfected, but I gotta run out due to out of school plans.
hope you enjoyed my post!

Sending good vibes,

Sean M. Raleigh; CS Major at WSU

From the blog CS@Worcester – Sean Raleigh's CS Blog by sraleigh62 and used with permission of the author. All other rights reserved by the author.

Welcome to my Website/Blog

Well, hello dear reader. You’ve come across my little section of the Internet.

To start, my name is Sean M. Raleigh. I am a Computer Science Programming major at Worcester State University, a beautiful campus with  hardworking, smart professors and kindly students.

In this blog, I am going to post solely work related content, mainly at first just to keep up with my Robotics class, but other content related to my skills and accomplishments will show up here as well. I will review various methods for programming, working with robotics, and other Computer Science related materials. I hope to use this Blog for the purpose of education and the sharing of knowledge.

I hope you find my site pleasing to the eye and enjoyable to read. Have a great morning, afternoon or night, and I look forward to writing more!

Until we meet again, dear reader,

Sean Raleigh; CS WSU Student.

Image Credit: — used for the purpose of review and education

From the blog CS@Worcester – Sean Raleigh's CS Blog by sraleigh62 and used with permission of the author. All other rights reserved by the author.