c.cc

Ruby Rewrite PID

We have continued our progress into rewriting the old python scripts into ruby following our object model. We have started to try and decipher the PID controller and how it is interacting with the data from the simulator, some of it makes sense, parts of it don’t, mostly what a set_point is. We can’t seem to figure out what this is, or what its purpose is, or why it is always 0 to start.

Due to this, we decided to give ourselves homework, yes you read that correct. We are going to do some more research into PID’s and how they work, then we will attempt to plan out our PID regarding the plane’s heading. This should give us a head start into our class time on Wednesday.

Challenges

As previously stated, we can’t figure out what the set_point is or its purpose. This is a small challenge, but it is important that we understand all aspects of these controls before we move forward with our plans. Once we grasp PID’s and how they work, we should make steady progress. We plan to overcome these challenges via homework and personal research.

Did You Know?

That self is needed in python and not ruby! This might not seem like much, but saving all that time from that four letter word can add up to minutes!

For example:

Ruby:

class myClass
    def myFunc(name)
        @name = name
    end
end

Python:

class myClass:
    def myFunc(self, name):
        self.name = name

For more information read here

Ruby Re-Write

We have decided to re-write the old code regarding auto-pilot in Ruby. Today was our first day actually coding in regards to this project, so it felt nice to see that we are moving forward with our goals. We decided to re-write the old code so we can have a better understanding of how it worked, and then address the issue of the dolphin tailing when changing altitude.

Current Progress

We have written the code so far in OOD, where prior it was done functionally. We feel that this will give us, as well as future extensions of the project a more maintainable code base, which is ideal for research projects.

We have the Ruby code working with a UDP socket class, then creating a class of ControlPanel, which allows us to separate the data coming out of the simulator into useable member variables which we plan to use later on in development. Even though this is a small step, it is a step in the right direction.

Complications

We have yet to begin our research into PID’s as well as the previous algorithm in the autopilot.py. We feel that we will be able to overcome these challenges within a reasonable time frame and hope to fix the dolphin tail issue well before Thanksgiving break.

Did You Know?

That the UDP set up is very similar in Ruby as well as Python. Also, Ruby did a lot of the work for us when we needed to split the string of data, as well as the accessor functions can be written with little code compared to other, more complex languages. This was a relief.

Workstation, Finally!

So, after a slight delay in our class, we have finally been able to get Dr. Jadud to set up the iMac workstation. We couldn’t be more ecstatic!

In our class tonight, we sat down with Dr. Jadud to go over some basics regarding UDP port setup as well as running python scripts with the simulator. We found this brief session very helpful.

Dr. Jadud demonstrated the auto-pilot script which was written by as previous student of his, and we have found an area where we can start improving it. Currently, the auto-pilot’s flight leveling system behaves in a strange way, where it seems to dolphin tail to maintain a level flight rather then just remain constant. This area is where we plan to make our first improvements on past work, as it will be the gateway, and a necessary fix before we can implement our plans for GPS waypoint navigation.

We went over some information regarding PID controllers, what they were and how they work. There needs to be further research done regarding the controllers so we can have a better understanding on how they work and how to implement them in our future scripts.

After further discussion, we are considering working in either Python or Ruby. It will be decided at a later date.

Did you know?

It takes 341 licks to reach the center of a tootsie pop? AMAZING! I am kidding, that was a little easter egg for our readers.

Setting up a UDP port is similar in almost every language. We saw two examples today and they were almost identical in syntax and complexity. This gives us hope that regardless of what language we decide to use, the complexity will be on par with other languages.

Flight Simulator Setup

After our meeting with Dr. Jadud and Dr. Pearce to go over our semester goals, we decided that setting up our simulation environment was the next step required for progress. Dr. Jadud informed us of FlightGear, a sophisticated, professional, open-source flight simulator. So, we decided to give it a try. The plan was to figure out how to fly a plane, and receive flight data via UDP. This did not happen.

Challenges

Due to the slow wireless network connection on campus, the downloading and installation took longer than expected. But we overcame this challenge by bringing out the ethernet cable. The program was an easy installation once downloaded. However, running it was a different issue.

We have two different laptops (4gb of ram, dual core), and one of them could not run it at all (Dell Latitude E5410) - graphics card not powerful enough, the other(Latitude E6400) could barely run it - it would freeze shortly after.

Still, we managed to get the plan in the air for a few seconds (before crashing or computer being frozen).

Solutions

We are planning on getting a Mac workstation, which should be more than enough to run this software and anything else that we will need to run. So, those issues of not having powerful enough hardware will not be repeated. Hopefully, we will have that set up by next week so we can begin learning the simulator and transferring flight data via UDP.

Planning & The Transterpreter

Today, class did not proceed as planned from last class period. We had planned on working with the Arduinos, unfortunately, some guy name Matt Jadud locked the Arduinos in his office. Consequently, today consisted of redefining the direction we want this course to go in. We have have decided that we should:

• Have a simulation environment set up that can occam runtime. We figured this is essential to any future progress so we can test code rather than just throwing it on a plane and praying for the best.
• Once we get the simulation set up and working, we would like to have a plane to fly, even if it means using the kit so we can see some code in life rather than just a simulation.

The remaining time was spent reading about the background of the Tranterpreter and about its structure and performance. Of course, writing this blog post was also part of the class. :p

The Transterperter

From our understanding of the reading, we were able to see that the Transterpeter still has room for improvement in speeds, but it provides a substantial boost in speed (10%) when running PAR. Based on our understanding of what we will be using occam-pi and the Transterperter for, this is essential. Due to us being limited in our hardware, we need to be able to have programs that have small footprints, and yet can be run at high speeds in PAR.

Did You Know

Using Occam and the Transterpreter is an excellent choice for introductory robotics programming in LEGO MindStorms Kit because:

1. It is a better introduction to programming than Robolab
2. The syntax is easy to understand
3. It runs smoothly on the hardware