Christmas news

I've been away from the blog for several days and I miss it! So, here's my catch-up edition. First, the sad news: our faithful Canon Digital Rebel XT died last night. An error 99 led me to a nice site with debug info (see update #2). After a bit of debug (shooting with no CF card, no lens, and a recharged battery) still showed the error, I noticed that the sensor cleaning mode didn't open the shutter. Oops -- almost certainly, the shutter is dead. We've used it for 4 1/2 years and close to 100,000 photos, so we've definitely gotten our money's worth out of it! It's now a toy for Alex and Daniel, so they're having a great time with it.

I've been doing some fun reading. It sounds like Boeing is finally ready with their latest plane, a small, economic airliner. It's a stark contrast to the gigantic Airbus A380, a concept I never liked. I've always preferred smaller airports to giant hubs and hope that Boeing wins out with a regional jet instead of a hub-to-hub behemoth from Airbus.

Another fun thing I ran across: nuclear reactor drawings (here are hi-res versions).

I finally had time to play with Skype and the Logitech Quickcam E3500 we bought several months ago. The two didn't work together and, reading on Google, I saw lots of complaints that the two companies blame each other for the problems. In particular, the webcam microphone wouldn't work, or sometimes worked inconsistently. I installed the latest drivers and software on the laptop and desktop to try again. The laptop worked fine; the desktop didn't. More Googling finally yielded the answer: if the mic volume is too high (>90% or so), then the webcam mic doesn't output anything. Unchecking the "Automatically adjust microphone settings" checkbox then manually bring the volume down fixed it. Amazing. Vika had a nice conversation with her family. There's lots of snow on the ground in Almaty -- they showed us a webcam shot of it!

I made some exciting progress on the professional fronts: I finally figured out how to deal with a troublesome term in the limiting-case analysis I'm doing with Durga. I'd thought about looking at a Taylor expansions, but didn't see any nice simplifications from that. However, playing with Maple, expanding just the first three terms produces a very small error. Wow -- I'd been puzzled by that for a long time!

I'm still excited about ARM stuff; I think I'll probably buy the proto board and see if I can find time to play with it during the semester. Speaking of the semester, some thoughts and plans:

For Micro, I hope to improve the course in three areas:

1. Make tests before I begin covering the material. That's just planning, preparation, and discipline.
2. Revise the labs and homework to require students in later labs to get an I2C, SPI, and A/D peripheral up and running. My plan is to develop that in the Spring then implement it in the Fall.
3. Create an in-class demo robot / revised Intro to Robotics robot / recruiting platform / summer camp robot. I think the same robot can serve all these goals, or at least the same basic robot with various minor modifications. Again, I'm planning on developing this in the Spring.

We'll see what I actually get done. That's quite a bit of work! I'll definitely be asking for some help with all this.

ARMed

I'm at home this morning. I tried using xUnit on my PC here and also ran into problems; it looks like xUnit is generating an "unable to load assembly" error. Sigh. I'll have to track that down. It might be easier just to create a console app and run that instead, though. I really miss not having a working test framework.

I did lots of clean-up yesterday, going through almost all the unread items in my inbox. Wow. That was really nice. I reviewed several SECON papers and was disappointed by the low quality.

Before I wrote Microcontrollers: From Assembly Language to C Using the PIC24 Family, I considered adopting an ARM instead of the PIC24. The main problem was the lack of prototype-friendly packing (all the parts were surface mount), but otherwise I really liked the parts. I ran across a nice ARM part again that I'm excited about, a family from ST, the STM32F series:

• It's based on an ARM Cortex-M3. I'd prefer an ARM Cortex-R4, since that has an optional FPU. While some companies have licensed it, I can't find any products from them yet.
• They have a small package (36 pins, QFN, 6mm x 6mm = 236 mils x 236 mils). Note that a standard DIP is 300 mils wide.
• Their best part in that package, the STM32F103T8, features a 72 MHz clock, 20 KB RAM, 64 KB flash, 2 UARTs, 4 timers, 10 channels sampled by two 12-bit 1 MSPS ADCs, 26 GPIOs, and one each of SPI, I2C, USB, CAN, PWM timer. The datasheet gives part-specific features, while the reference manual gives info common to all the STM32 parts. The programming manual discusses the core and its instruction set.
• They have what looks like an excellent standard peripheral library, which looks equivalent to the library I co-wrote for the PIC. It's well-documented and looks fairly useful. It comes with example code for every peripheral and seems to include clock config and everything!
• Their programmer/debugger, the ST-LINK, is $24. Wow. I like that. The user manual gives more details.
  
• They have a bootloader with dlls to link to plus a GUI; I haven't tried it, though.
• The errata list looks reasonable, a contrast to PIC24 errata.

The biggest cons:

• No DIP package. Doing a quick search, there's an adapter board out there, thought it's fatter than I'd like (600 mils). Here's another option. It would mean having someone build these boards; I bet SparkFun would do it for us.
• It's soooo painful to get another micro up and running. It's even more painful to turn this into a class. Writing another book adds another level of pain.
• There's no reason to do this. The PIC24 is fine for what I'm doing, even in the foreseeable future. I don't see any new things an ARM would enable me to do in terms of research.

Some getting started notes:

• Bootloading:
• To enter the system bootloader,  set BOOT[1:0] = 01. However, the STM32F103T8 has only a BOOT0 pin in the 48 and 36 pins packages.  It looks like BOOT1 is shared with PB2 per the pinout in the datasheet (page 27). I could do this via the FTDI cable with a weak pull-up on PB2 and RTS connected to BOOT0 (see e.g. page 14 of AN2586).
  
• Per AN2606 page 6, the built-in bootloader runs off the internal oscillator at 24 MHz. It uses PA10 and RX and PA9 as TX and operates at 8 data bits, even parity, 1 stop bit. Per page 8, it uses autobaud and works from 1200 to 115200 baud. It's possible that higher rates would work, though.
  
• AN2586 is a hardware getting started guide.
• The NRST (low-true reset) has a built-in pullup, per page 10; all that's needed is a pushbutton!
• Per page 52 of the datasheet, the internal clock is accurate to +/-2% at 0-70 degrees C.
  
• There are 5 pins for program/debug; however, user software can take control of them as code executes, disabling debug abilities. However, the standard connector is a 20-pin beast, only 5 pins of which must be used. There's a 2-pin mode, which would be nice. I'm still not sure how these work.
• From the clock tree (page 78 of the reference manual), it looks like picking the internal 8 MHz source / 2, then using an x18 on the PLL gives 72 MHz for full-speed operation.
• An odd thing: since the bootloader is permanently burned in the part, I don't need a programmer; I'd only want that for debugging support. That's nice.
  

I found a neat trick: to create outlines of text for laser cutting, Word plus Visio works: create WordArt in Word (Insert tab, click WordArt). After creating it, click on the shape, select the WordArt tab, then choose Shape Outline, Width, Weight of 0, color red, no fill. I can't figure out how to set the proportions correctly, though.

Now back to work. Forms to fill, e-mail to answer...

Testing code

The more I use it, the more I like it:

• All code should be tested, if at all possible, using unit or functional tests.
• All builds should be automated, particularly for complex builds.

The interval analysis paper I'm working on has benefited from these two: I've started a simple functional-test framework which has found several bugs. Work on an auto-build also makes life much simpler.

xUnit / TestDriven.net stopped working mysteriously and I can't get them going, in spite of updating to the latest version of both! Ouch.

The weeks is vanishing

I'm shocked and amazed -- the week is vanishing. Wow. Today and tomorrow, then I'm done for the year!

Some fun reading: from the IEEE, automated to death (including a truly scary video simulation of a 777's autopilot going crazy).



I found another possibility for a demo robot chassis: a simple tracked robot. I'd like to use one robot for both Intro to Robotics, a summer camp, and a Micro demo robot. The one thing I'd like is encoders; the other question is power -- can this robot carry an arm? Update: here's a better link, including a video, plus a post on hacking in encoders.

I merged the data transfer code in to the main ECE3724 development line. That was more painful than I'd expected, but I think it all works now. I need to document what I've done, so others can use it.

The end is near

I've decided to work the rest of this week, then spend the rest of the year at home with my family. That's not much time to wrap everything up! As always, I need to select the most important things and work on them.

I spend half of yesterday in a meeting on ABET data collection. Our next program review comes in Fall 2011, which means I'll need to start copying three papers each of good, average, and poor students for EVERY assignment I give in every class I teach. Fun. Time to kill some trees. I'm still finishing up this semester's data collection task to enter my ABET data for Micro. Fortunately, I developed a spreadsheet that makes this much easier.

I came to the meeting at 8:00, but it really started at 8:30. Sigh -- while our department uses Zimbra, I certainly don't. I tried it which just released and found it buggy, under featured, and slow. Perhaps one day we can move to Google (Calendar/GMail/Sites/Docs/etc.). There was an update on the time, but I somehow missed it.

On Monday, I submitted the Jacobian paper a day early. I'm glad I did, because MSU's internet went down yesterday afternoon, which would have made it hard to submit the paper.

I finished up the data transfer program, getting the GUI fully working. It took forever for me to figure out that I needed to specify an Windows-1252 encoding to get binary data passed through correctly. I'd like to post a few docs and demos when I have time. It's a nice interface, though some improvements still need to be made. The next big coding project will be adapting this for use with MATLAB by adding a C-callable backend for the GUI. I'd found earlier just the right class to help, but now I don't remember. InvokeAction? InvokableAction? Perhaps using a Control.Invoke (here's a tutorial) will work to make thread synchronization easier.

Today is mainly a catch-up day: go through e-mail, etc. I hope to at least look at Durga's paper, though.

Busy as always

Somehow, I tend to think that during the holidays I can finish everything, do a few fun things, etc. Sigh; that doesn't seem to be the case. I think the list is growing, rather than shrinking! The updated list:

1. Move ahead on Durga's paper. It's due tomorrow. The text is in fairly good shape, but the plots all need to be re-created from code yet to be debugged.
   
2. Marketing! Come up with slides, videos, etc. to communicate our funding ideas. Meet with Lori, Gary, etc. to ask for their help.
3. Work on my data transfer code. Just a bit of GUI tweaking and it's ready for release! It (basically) works!
   
4. Learn more about continuum mechanics:
1. Read through the nice thesis Krishna found, read the book Buddy found to better understand continuum mechanics.
2. Read up on and post ideas on using MATLAB's boundary-value solver.
3. Read up on Buddy's progress through Antman's chapter on numerical solutions to continuum dynamics.
5. Review SECON papers.
6. Improve the SECON spreadsheet to add in the motor calculations. I found a silly mistake in my write-up, I'm thankful I saw it.

I spent some time with Inventor Professional on Friday trying to clean up mechanicals for the Intro to Robotics laser cut, which has two servos mounted in it. Inventor is such a terrible tool. Trying to export it to anything useful completely failed; only AutoCAD can ready the dwg/dxf Inventor produces; Illustration can open a PDF, but that file doesn't quick scale right when pasted to Visio. Grrr.  There's some mechanical info from Servo City, but I'm guessing the controlling dimension really should be mm instead of inches. I say this because Hitec gives servo dimensions mm; both Hitec (Korean) and Futaba (Japanese) are not US companies. However, being off by a few mils probably won't matter.

Video and grading

I ran across a fun video reading IEEE Spectrum. It's amazing what fun and creative things are out there!



Today is a grading day; I'll be going through the Advanced Robotics stuff. I'm also now trying to get Durga's paper ready to submit by Monday (yikes!).

I worked a lot on the data transfer code and got a preliminary version up and running. It works! I'm very excited. Now I'm puzzling about how to nicely format and print data: if I have the data as an array of bytes, how can I easily format it using printf format specifiers, etc.? To do so, I'd need to cast the data to the correct type, which involves parsing the format spec, which isn't fun. In contrast, scanf will read data from a format specifier into any pointer, which is exactly what I want done on the write side; I'm just missing the read side.

Mobile computing

I'm waiting in the health center for lab work for my annual check-up. I'm soooo thankful to have a laptop, where I can get a bit of work done.

Alex and I hung lots of Christmas lights on our house this morning. That was fun! He handed me clips while I hung lights. He got tired after a while, so I finished the last string by myself. I was surprised -- his help really made the job easier!

Something neat: I found a conference in Novosibirsk; I've e-mailed the organizers to see if the Jacobian paper might work. I'd enjoy getting to go there, if that's possible. If it is, I'll really need to jump on the paper to get it in conference form.

I'm done with Micro grading; now, on to Advanced Robotics as papers come in.

Tommy pointed out an MSU robotics team from Industrial Technology; I need to meet with the group to see what they're doing!

Embedded Python

I heard that a company (Synapse Wireless) can run a Python subset on an 8-bit micro with 40K of program space left over! Amazing. Searching the web, I found the Python-on-a-chip project, which looks quite interesting. An associated discussion group has a nice list of embedded Python projects and their status. Very interesting. I wonder if they have a PIC port.

Finals are done, I'm grading now...

Final final

I'm current giving my final final. The semester is almost over! It's time to get organized by planning what I can do now, between semesters, while it's still quiet.

1. Grading - of Micro and of Advanced Robotics. I'll start Micro this afternoon, after my students have finished taking it.
2. Setup and software install -- I need Visio on my laptop. I've already install Dropbox, Chrome, Testdriven.net, xUnit.net, and got MSVC++ configured.
3. Develop Micro - I'd like to create an in-class demo robot plus use that for a minority-focused summer school. I'd like to have a preliminary budget by this afternoon for my 3:30 meeting with Tommy.
4. Marketing! Come up with slides, videos, etc. to communicate our funding ideas. Meet with Lori, Gary, etc. to ask for their help.
5. Work on my data transfer code. It's almost done...just added another unit test...
   
6. Move ahead on Durga's paper. Still a fair amount to do there.
7. Learn more about continuum mechanics:
1. Read through the nice thesis Krishna found, read the book Buddy found to better understand continuum mechanics.
2. Read up on and post ideas on using MATLAB's boundary-value solver.
3. Read up on Buddy's progress through Antman's chapter on numerical solutions to continuum dynamics.
8. Review SECON papers.
9. Improve the SECON spreadsheet to add in the motor calculations.

One thing I learned: have a final draft of papers due earlier and carefully edit those. I'm reading the final versions of these papers, but my comments don't help my students by leading to corrections and improvements, since I'm reading their final paper, not a draft.

I just switched to Google Chrome instead of IE, so I can read my e-mail there while Vika works in Firefox. So far, I like it!

Inbox fun

Krishna found some interesting links to various snake-like robots that I'm working through this morning.

• The NASA space SnakeBot looks interesting, but the creator of the bot seems more focused on reconfigurable robots. His most recent paper (a review) reference work from 2002, suggesting it's not a current topic.
• The Cornell SnakeArm team: I'm not sure if this is an undergrad or a graduate effort. The professor (Francis Moon) listed on their page doesn't seem to specialize in snake robots. Their video (see below) sugests they have a great mechanical design, but no kinematics. It's probably worth contacting them!

Other than that, I'm just working through my inbox, preparing a final, etc. As Krishna says, we really need a good video of our robot to show the world!

Also from Krishna in my inbox, a nice thesis provides a good background an introduction to Cosserat rods, plus good diagrams that explain shear and bending strains.

Still sweeping

I'm still sweeping away, getting lots of random things done. Praise the Lord for time to do this! I even had a chance to work on the PIC/PC data transfer code, which I enjoy.

I saw some solar cells from Edmund Scientific that output 8.5 V at 250 mA. That sounds fairly attractive, since it should avoid most of the boost/charge pump frustrations for the team.

I got an e-mail from a faculty member adopting the book I co-authored. That's very encouraging!

Sweeping

I realized yesterday that I'm sweeping. After building something in a workshop, the final step requires putting away tools and sweeping up wood chips. Likewise, the end of a semester is an end of project time, so I'm filing, cleaning, reporting, updating, and so on. It's good to understand the time I'm in, since I'm making little research progress. However, this time of preparation will enable me to begin the next semester well, when I start another project.

To be swept:

• Update the research group home page with recent pubs
• Finish grading advanced robotics
• Finish and submit the SECON paper
• Submit the ONR application
• Work on the Air Force application
• Prepare a Micro final
• Clean my desk
• Go through e-mail
• Attend the SECON presentation

I'm working with latex again. Ugh. I still prefer Word's quirkiness with figure placement and creation over Latex's cryptic commands and the edit/compile/verify cycle.