Archives for posts with tag: Robotics

Recently, I wanted to play with the latest build of MeeGo on my Nokia N900. I also wanted to try it on a PandaBoard borrowed from a friend. To do that, I needed a better (greater capacity and higher write speed) microSD card than any I had in my collection. That need caused me to learn more about microSD memory cards. The results of learning about microSD and the speed classification were somewhat disappointing.

According to this article on Wikipedia, a Class 10 SD device is supposed to provide a minimum of 10 Megabytes per second in sequential write throughput. What I found is that, in reality, SD Class ratings are on a par with the claims of used car sales.

In order to try and objectively establish the actual throughput of various microSD cards, I needed some software tools. I’ve used two so far. ubuntu distributions include the Disk Utility, which will measure disk speeds. I believe the tool will only measure sequential writes, not random writes. It also doesn’t allow for any configuration of the testing characteristics, such as block size or file size or number of testing threads.

I also used the Linux utility fio. This is a much more comprehensive and capable tool, allowing you to configure essentially every aspect of its operation.

Using both of these tools with the first microSD card I bought for this new project, I was sorely disappointed. I bought a new Lexar 8 gigabyte microSDHC Class 10 card. The Class 10 states that the card is supposed to be capable of a minimum of 10 megabytes per second in sequential write throughput. My test results indicated otherwise.

Using both the ubuntu Disk Utility and fio, the best I was able to achieve was less than 3 megabytes for sequential write throughput. Using fio to execute a random write test, I learned that this Lexar card wasn’t capable of even one megabyte per second for a random write.

Now, I’m on the hunt for microSD cards with at least 8 gigabytes capacity, which will give me at least 5 gigabytes of throughput for random writes.

Advertisements

I firmly believe that every job is easier with the proper tool. Often times, when troubleshooting an issue with one of my hobby robotics projects, the proper tool is an oscilloscope. However, my hobbyist budget doesn’t allow for the purchase of a full-feature benchtop digital ‘scope. I also don’t use it often enough to justify spending a lot of money on a ‘scope. Admittedly, I also don’t know enough about all of the intricate details of fully utilizing all of the capabilities of a ‘scope. Therefore, the best solution for me is one of the many brands of inexpensive ‘scopes which rely on a PC (usually a notebook) for the display and the data capture. Through my employer I was able to get my hands on a BitScope. In this article I’d like to describe the ‘scope and my experience with it.

First off, the BitScope is shipped from Australia so they don’t generally show up overnight, just in case you require instant gratification from your electronics purchases. This ‘scope arrived in about a week, none the worse for wear.

The reason I selected this particular ‘scope was, first and foremost, because it’s officially supported in both the Linux and the Windows environments. I’m a Linux user but my employer is an all-Windows shop.

I ordered a model BS325. The back of the unit I received appears in this photo:

Image

This brought me to the first wrinkle. The sticker makes it seem like I received a BS326N. I extracted the board from the metal case (which is very easy to do and a nice part of the design) and looked closely at the board itself.

Image

The board is clearly labeled “BS325N” but the sticker on one of the modules clearly states “BS326N”. At this point I assumed those two model numbers are equivalent.

As I mentioned earlier, this unit only has an Ethernet interface. BitScope also includes a crossover cable, for a direct connection between the ‘scope and my notebook computer. Herein I encountered the next wrinkle.

I attached the crossover cable to the ‘scope and my Windows notebook. The Data LED lit solid but not the Link LED. I moved the cable to my Linux notebook but saw the same behavior. Through some more experimentation, I’ve since determined that the labels on the LEDs are switched: The LED labeled “Data” is actually the “Link” LED. Again, not really a big deal.

The next thing to do was to actually configure and try the software. BitScope includes a CD with the software for Linux, Macintosh and Windows. Seeing this warmed my heart. I installed the software on my Windows notebook and my Linux notebook. Then I attempted to connect the software to the ‘scope. Yes, next wrinkle.

The page in the included paper manual looks like this:

Image

Since I had ordered a BS325N, the board said BS325N and the stickers said BS326N, I assumed I should use the factory IP address for the BS325N. Nope. The IP address actually assigned to the ‘scope was 192.168.1.73, the one listed for the BS310N. Once again, not a big deal.

I did manage to start the software, connect it to the ‘scope and query the ‘scope. The Windows software identifies the ‘scope as a “BS032600”, by the way. I made a few simple tests and played with the software a bit. I tried the same simple tests on my Linux notebook, but the bitscope-dso software complains and then aborts.

I’m still satisfied with the ‘scope and happy to have it. Obviously, their manufacturing quality control needs some improvement but it’s not keeping me from using the tool. I had also contacted BitScope Technical Support when I was looking at the lack of Link issue. It took them almost two days to respond and I was disappointed to receive the all-too-common Technical Support response. Essentially, I was told “This is almost certainly your problem. Check your firewall and network configuration”. The Technical Support staff apparently either didn’t read my note or doesn’t understand networking issues.

Next, I plan to use the ‘scope to troubleshoot some actual conditions in my lab. I’ll provide some more details on how the device worked for me.

A large part of developing robotic systems involves measuring the state of the robot and then executing some action, to change the state of the robot. Because there is usually not an exact correspondence between the action and the desired state and because it’s also usually necessary to measure the new state, some method of control is required. It’s helpful if the control method can take into account all of the current state of the robot, the previous changes to the state and their corresponding effect and the new state. One typical method is called PID control.

PID control is useful when the state of some part of the robot can be measured and represented as a numerical value. The actual value is the difference between the actual measurement, called the process variable, and the desired measurement, called the setpoint. The PID control works to bring the difference between the process variable and the setpoint to zero and keep it there. As an example, assume we have a robot which we wish to move at a constant speed. The speed of the robot is based upon the voltage applied to its drive motors. Apply more voltage and it goes faster, apply less voltage and it goes slower. The challenge arises because the change in voltage is not instantaneous and also because the robot is not always travelling over exactly the same surface and with the same load. Sometimes the same voltage will make it go a bit faster and other times a bit slower.

The PID control attempts to reduce the difference between the process variable and the setpoint by calculating a control value and then applying that control value to the process. In our example, the setpoint is the robot speed wanted, the process variable is the actual, current robot speed and the control value is the voltage to apply.

Proportional Gain

The first part of the PID control is the proportional or P adjustment. This is, perhaps, the simplest part of the PID control and responds in proportion to the difference between process value and setpoint. When that difference is large, the P control produces a large control value. When the difference is small the P control produces a small control value. So, let’s say that the voltage range in this example is from 0 to 12. 0 Volts causes the robot to stop (eventually) and 12 Volts causes it to travel at its top speed (again, eventually). We can then write an equation to calculate the control value, based on the setpoint and the process variable:

ControlValue = [P x (SetPoint – ProcessVariable) x (MaxVoltage – CurrentVoltage)] + CurrentVoltage

The ProcessVariable is the current speed of the robot. The SetPoint is the desired speed. The CurrentVoltage is assumed to be what’s causing the robot to move at its current speed. P is the proportional gain, from the P in PID Control, and is used to determine just how much voltage change is applied to the current state of the robot, in order to move the ProcessVariable closer to the SetPoint.

At this point, what we have is a way to adjust the speed of our robot, which responds proportionally to the difference between the actual speed and the desired speed. In other words, if the actual speed is close to the desired speed, this control method will only make a small adjustment. When the difference is great, a large adjustment will be made. This would seem to be a good thing, until we consider latency, in terms of the delay between measuring the speed and responding to the speed and in terms of the delay between applying a new voltage and reaching the full effect of that new voltage. Because of these possible latencies, the system being controlled can have a tendency to oscillate, above and below the desired speed, and never actually reach the desired speed.

Fortunately, the PID control method can deal with that and it’s specifically the D part of the method which I’ll describe next.

Derivative gain

to be continued …