Category Archives: Work-Related

Software Construction, Design, and Architecture: Post 2

Hello Reader. I’m back here again, ready to cover another day in class.
So, it turns out I’m going to have to modify this and some of my past posts, so that they are grade-able for the class. Otherwise, my posts are still gonna follow the same sort of format, where I just candidly cover everything going on in class, as much as I can.

It’ll include a reflection on the material and I’ll be answering  some questions put forth by my Professor, Dr. Wurst. As for right now, I’m preparing to take on whatever we have to get done for today.


Come to think of it, there is a word count restriction on the posts for the class. I will make separate posts for those questions, specifically.


We are talking about UML Class diagrams today. They are the most commonly used UML diagram. We use these diagrams to put on paper what makes up a software program, from the classes set up within the program, to details about said classes, and then the relationships between classes.


First, you have the class name. Within a box divided into three boxes horizontally, the top box is the class name. Then, you have their properties, second box. Finally, the last box contains methods that the class/other classes (depending on its visibility) can call on to use.


 

Sorry I havent uploaded this, not going to add onto anymore as of now but just uploading what I wrote.

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.

Lab 3: Obstacle avoidance and Multi-process systems

Before I would like to start, I would like to speak openly here for the intelligent Dr. Wurst, my professor, to ask him something really quick.
Would this blog post count as acceptable for a lab notebook entry? It would be a pleasure and a great convenience if you will accept this!

I will answer all of your questions in the following paragraphs and write about me, Urooj, and Braxtons time working on Lab 3 for Robotics.

Let us begin.
Today, I am working on finishing up our multi-process c program that will have the robot adjust its direction and speed at the same time, thus two processes working in a multi-process system can be observed.

If we had approximately four or so hours straight to spend on this lab, we would have completed it all in one day in my opinion.

But that is fine, now I am back and now I am more than ready to solve some problems!

There begs a question: What will I do first? Well, right here and right now is a start. Keeping steady lab notes and tracking everything I do will be most beneficial for us all in the long run, as we all can learn easily about anything — we must simply have a passion for whatever it may be!

I apologize. I am writing much like a Philosopher. One could say I am a philosopher of technology. With this out of the way however, I would like to actually get down to business. I will now begin [:chuckling:]

I am going to produce a program to read the Sonar Sensor attached to the 0th analog position in the Botball device. After I do this I will begin to track the sensor readings for the following materials and light levels.
If my hypothesis is correct then light levels will not affect the Sonar sensor, as it uses echolocation to sense its surroundings. What a smart device truly!

However if I were to attach light sensors and IR sensors, I could create even more functionality to the robot.  Heck, imagine if I put a camera on the front of the robot to stream to my phone! And a bluetooth keyboard to have the user gain full control of the robot itself.
Goodness, technology endlessly brings me so much interesting new stuff to work with! Okay, I am going to stop writing here now so that I can accomplish the programming for the Botball.


Attempt Number 1: Robot keeps moving forward, stops to check IR readings (sensing left value vs right value.) but fails to adjust course in second function. Layout of functions: First function is the IR reading function, then comes the DRIVE function. The IR reading (and, well, writing as well) function keeps track of the devices input readings and adjusts variables so that the drive function performs as we want it to — to avoid obstacles or turn around if there is no way forward.

Changed motorValue from changing using is equals ( == sign) with = sign. Maybe program will work now. Attempt number 2 will be detailed in the paragraph/s below.

Attempt Number 2:
Attempt 2 was a success!! The robot followed the instructions perfectly this time after setting each analog state (0 and 1 as floating points) and used multiple functions in rapid succession. Time to implement C multi-process capabilities and if this works the robot is all set. Its behavior is to like stimuli and approach it (when it senses more from one IR to the other, it goes towards the stimuli closest.)

Attempt Number 3:

Pre-program test: Using multi-process function in KIPR C programming environment means I might not be able to use the defer method. Initially I would have used this in between processes to defer the need of one process to the need of the other process. Let us try to see how it works.

Post-program test:

Robot functionality lost while using start_process and kill_process. Maybe I should use kill_process in while loop? Next attempt will be below.

Attempt Number 4:
Put the start processes and kill processes before and after with while loop. Did not work. Now attempting to change kill_process(0 and 1) to kill_process(1 and 2). Maybe this will finally work?

Attempt Number 5:
Everything is balls [:tears forever:]

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.

Quality Software Design

Note: I don’t use Emojis in plain text, so I label my reactions a specific way
I denote it the following way as to give the reader a sense of my personal mental thoughts or reactions towards something. It’s kind of like an Emoji… Except its just boring text! [:laughing:]

Sub-note: Apologies for not updating for this class for a few classes. I’m working to get back on track!
We begin today by speaking of good software design. Lets talk about it.

Some qualities of good software design? One quality that well-made software have against poorly-made software is that it shows a large variety of functions and features related to its purpose. Another is the ability to add new features seamlessly. Java allows us to do this throughout its classes. These classes can interact with one another, have many variables and many different methods (or functions.)

Java is a well chosen example of a good software designer, as it allows for easy creation of objects and systems that work together to make one whole large system. It also allows for massive levels of modification and for addition or deletion of content on a whim. It is all up to the programmer!


There are also difficulties to come with the advancements seen in Java. One must learn of its many ins and outs to be able to successfully conjure up oneself a piece of beautiful software!


Lets say we have a player class, and it has methods that pertain to a player of a video game. Then, a character inherits or extends this class, but overrides unnecessary methods within the class. The player class is a interface if its subclass inherits from it, and if a subclass inherits from it, its an interface.

Otherwise, the player class is an abstract class. An abstract class has its subclass extend from it.


In the big picture (according to our professor Dr. Wursts slide) there are two main things to consider: the IS-A relations and the HAS-A relations. The person class is a class. The person class has a method/s and variable/s.

Mainly, today we have been talking a lot about the things we can do in a Java-based system. I know I haven’t been as detailed as my last few posts, but regardless, I hoped you enjoyed the read!
(goodness even the caffeine could not drive me to write well today! [:laughing:] )

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: 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:

20170907_152756.jpg

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.

https://i1.wp.com/static.pexels.com/photos/34676/pexels-photo.jpg?w=625&ssl=1

Image Credit: https://static.pexels.com — 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.