Road Testing an ARM LPC2101: Part 1a

In the previous article, I soldered an LPC2101 onto a Schmartboard for testing. The low cost ARM7 MCU was sent by Newark to me for road testing. Part 2 was intended to discuss programming the device, but programming turned out to be substantially more involved than I expected.

LPC2101/2/3 Breakout

Meanwhile, the chip fried during experimentation, halting my progress. I subsequently designed a breakout board for the LPC 210x family of MCUs and assembled the first set of parts onto one of the boards to try it out.

Downloading a hex file to blink an LED was successful!

I've also successfully programmed the UART and sent "Hello World" over serial. Cool!

Features:

• Compact 36-DIP package for breadboard prototyping
• Uses standard FTDI 6-pin header for bootloader programming and serial debug
• Program switch makes it easy to flash new programs via bootloader
• 800mA 3.3V onboard regulator to power MCU and attached circuits
• Onboard 1.8V regulator reduces power complexity for the experimenter
• Three supply options: FTDI, VIN pin, or external 3.3V supply
• Reset switch
• Debug jumper
• Pin 0.14 is exposed for automatic program mode with RTS

Eagle Files

The board's Open Source Hardware so here are the Eagle files, Gerbers, etc.:
http://code.google.com/p/bt-arm-breakout

Coming Soon

This new development platform and the switch to an LPC2103 made it easier to get sample programs working.

The ARM7 is a bit tricky to get started with because one must include startup code in assembly with the chip to set up the stack and other configurations.

One must also set up a memory map within the IDE. More details to follow in Part 2, coming soon.

Eventually, I will undertake a similar road test for a Texas Instruments ARM processor, also sent by Newark for road testing. Stay tuned!

National Robotics Week 2012

April 7-15, 2012

This year, National Robotics Week is April 7-15, 2012 and I'm going to participate by releasing my robot minions to take over Denver! Ok, not quite.

But I am hosting another Data Bus Demo Robot Party on April 14. The bright yellow robot will once again have a chance to show off or fail miserably in front of a crowd. I've invited a few other AVC competitors to join in, too. Should be a fun time!

Already a bunch of people have RSVPed in the affirmative so I better get my crap together and get this bot working!


If I can break away from work, I may also participate in Automate Denver! an event that will bring robotics companies and hobbyists together at to display their creations and raise awareness here in the state capitol.

Magnetometer Calibration Machine

It's simple, it's cheap, and easy to make. What else would you expect on this blog?

What is it? A calibration machine for gyro and magnetometer sensors.

To help with my struggles in magnetometer calibration I've built a large, non-magnetic turntable device with encoders for precise and accurate angular measurement. The device is big enough to fit Data Bus or any other 1/10 RC chassis. Here's how I made it...

Magnetometer Calibration Error

In building my Sparkfun AVC robot, I wanted to investigate the effects of magnetometer calibration on heading error.

I've been working on calibrating my compass and have run into some snags along the way. I'm working on a calibration machine to measure real world error but I thought it'd be interesting to model calibration error first. Here's how. Time for Octave and and simple trig....

AVC: Is a 3D Compass Necessary?

As you may know, I'm working on Data Bus, my Sparkfun AVC robot (in case you missed it, I'm now officially on the active participant list!)

Having evaluated a couple of AHRS (attitude heading reference system) solutions, and after wondering if a compass was even necessary at all, another fundamental question arose. Suppose I do use a compass...

Do I really need a 3D, tilt-compensated compass in the first place? Or can I get away with a much simpler 2D compass? How much heading error can I expect from a 2D versus 3D solution?

Scott (Team Tobor), AVC winner for the last two years, employed a 2D compass heading calculation. Of course he also fed this value into an Extended Kalman Filter (EKF) along with odometry heading calculations.

What should I do? Time for more math, Octave (Matlab), and Gnuplot fun. Let's figure this out...

Sparkfun AVC: I'm IN!!

This just in:

I'm now officially on the active list for the Sparkfun AVC 2012!

Just got the word today that enough teams dropped to move me onto the active list!

Data Bus and I are very excited!

Review of CS 373: Programming a Robotic Car

I signed up for CS 373 provided by Udacity.com on a whim. I don't really have the spare time, though the topic seemed very apropos to the AVC. And I simply couldn't pass up on the opportunity.

I'm glad I didn't because the course is amazing and well worth the time. I can't believe it's free! I so wished any of my prior college courses were even half this good.

I've made it through Units 1 and 2 and completed homework for Unit 1. Prof Thrun covers Monte Carlo localization in Unit 1 while Unit 2 is focused on Kalman Filtering.

Excellent Teaching

Unit 1 surprised me in that Prof. Thrun distilled complex ideas into simple, intuitive, fundamental concepts. That this fellow is not only the brains behind the Google self-driving car but also a very skilled teacher is a tremendously rare combination and of invaluable benefit to anyone who can seek his tutelage.

Homework

The first homework was difficult for me. Appropriately challenging, I should say. Part of it was that I was carrying some baggage from a class on decision making and probability. I knew just enough to screw myself up. Eventually I got it. At least, I think so but I won't know until the grades are posted.

Learning Kalman Filtering

Unit 2 presents a topic that I've struggled with off and on for a year now: Kalman Filtering. I have previously spent many hours reading and working examples out of Zarchan's "Fundamentals of Kalman Filtering" which is a good book, mind you. I felt somewhat comfortable in developing a simple Kalman Filter.

To this knowledge, the CS 373 course added quite a bit of foundational concepts in the same intuitive, simple way as before. I feel I understand the concept behind Kalman Filtering much better and from recent exercises with linear algebra, I even think I grasp the math, somewhat. This is nothing short of miraculous.

Python

The course requires programming in Python with which I've had no prior experience. I have, however, programmed in around a dozen different languages over the last 20 years. Most recently I've been learning SPIN (the Propeller chip high level language) and Octave (Matlab) both of which have been helpful in picking up Python. Numerous Google searches have been instrumental as well.

Conclusion

So in short, I highly recommend taking this class to gain a more intuitive feel for the concepts covered. One can return to such basic core concepts when understanding of more complex situations fails, I think.

And, if you pick up Python as a side effect, that's an added bonus as it appears to be an extremely powerful language.

Eagle: Managing parts with BOM-EX

I want to share a time-saving tip with you: the Eagle ULP script suite, bom-ex.

Here's Why

If you've designed and populated your own boards, you know that it's easy to spend lots of time finding the right parts.

A typical, simple board, like the LPC2101 breakout board I'm working on, has about a dozen unique parts. Big deal, you say.

It takes me about 5 minutes to find a suitable part using parametric search on DigiKey, Mouser, Newark, etc. A dozen parts means an hour of parts searching.

Wouldn't we all like to spend some of that time fixing your code or something? Besides, what about the next board you make? And the next? And the next? Having to search over and over for things is, well... sub-optimal.

There is an easier, faster way, my friends.