PIC Programmers

Got my parts today, and finally started building and testing my programmer. I was actually amazed at how few changes I had to make to get it working - there was two problems with the MCLR signal, and everything else is working nicely. Next I have lots of testing to do with peripherals, but at least I got the "hello world" LED to turn on and off. Schematic is updated, and can be found at:

http://sites.google.com/site/zambots/project-files/MCU_boardandProgrammer1_1.pdf?attredirects=0&d=1

Also took a couple pictures of the current setup. Here is my programmer, with the Arduino XBee shield beside looking pretty.

Finally, how do I program the PIC? This is a slightly complicated process...

1. Download the required software. I have found success with ICProg (http://www.ic-prog.com/), with MPLabs IDE and their C18 compiler (Lite/Student)
2. Setup your project in MPLabs according to their tutorials/user manuals. Get all the include files necessary for the C compiler to compile and link, and build. This generates a hex file.
3. Run ICProg. First time setup will require you to also download and run the XP/2000/NT driver (icprog.sys) if you are using one of these OS. Not sure if it works for Vista or 7, and no idea what a good Unix hex programmer is.
4. Side note: ICProg also allows you to do hardware tests. This sets the serial pins hi or lo for you to test your programmer's response with a DMM.
5. Select your PIC (or other MCU), programmer (mine is similar to a JDM) and use the Windows API setting. I have I/O delay of 4. Com 1 is the serial port on my comp. Usually 1 and/or 2 are serial ports. Hit the Program All button!
6. This will take some time (maybe a minute) and will put your program onto the micro. Unfortunately with my circuit the data only goes one way so it can't verify. Hope to fix that with my last opto-coupler for the next iteration.

I know those weren't super detailed instructions, but all of those steps individually are well documented in forums, blogs etc. its just getting the correct order and a full set of hardware and programs that work together that is the tricky part. This one seems to work pretty well for me.

Next steps for me will be verifying the other peripherals (wireless, ultrasonic) and getting them working with the PIC, and mounting the whole thing on a more portable and nicer looking protoboard and inside a box where it can't be destroyed. Then back to the Arduino to write some mapping algorithms!

Arduino Fun

Started playing around with my Arduino today. Got it working with the ultrasonic sensor, super impressed by how easy it was to set up and test stuff. USB interface and quality (and open-source) software package makes things so easy! Probably had the ultrasound returning calibrated distance data to the computer screen within an hour of taking the Arduino out of the box. Something tells me the PIC with homemade programmer and freeware software will not be as easy.

Next I started playing around with some of the math functions to see what my options are in terms of room mapping algorithms. A sine calculation takes about 10ms, which will be a serious barrier. I need this one because I will know what direction the robot is facing (relative to the room frame), and how far a wall or object is, so to plot it on a room-frame map I will need to take the sine.

After pages of drawing and discussions, my brother and I formulated a potential algorithm for mapping and vacuuming. Let me try to explain (see the diagram):

1. The robot rotates 360 degrees to scan the room where it starts. The area it can see (un-occluded) is shown in grey. It will see mostly walls (or beds or tables) and then a small gap which could be a doorway, space between desk and bed etc. This gap is represented by a dotted line.
2. The robot positions itself near the gap and scans around 360 degrees. Either it will fill in the gap (maybe this was a small, open closet) or the gap will remain open (eg. doorway, large space). If the gap remains open, it is marked as a doorway, and the room inside the doorway is marked for cleaning. If it is closed, the new area enclosed is also marked for cleaning.
3. The robot then cleans the "room" that it has identified.
4. If there is one "doorway" (dotted line), the robot drives through and scans the new "room". If there are multiple, it notes the location of all of them, and then chooses the closest one in its bank of un-scanned doorways to drive through and scan.
5. This process is repeated until batteries run out.

Essentially what is happening is the robot will partition the room in real time as it discovers it, and clean small portions at a time. This is similar to the way a human would clean a carpet or floor.

Some drawbacks I see (I'm sure I'll discover more as I go along):

1. Could be tricky if the room is very large or open. It may be possible for the robot to spend all its battery energy attempting to enclose an area for cleaning, without doing any of the actual cleaning.
2. Doesn't take advantage of the fact that the room generally will look the same from week to week. There is very little storage and reuse of maps.
3. Representing the room in the robot's memory will be tricky. Currently my plan is to overlay a grid on the room, and have the robot identify which squares are occupied by walls, tables, etc. and which need cleaning. Memory usage will be inversely proportional to the resolution required (which I think will be around 10-15cm square).

And a couple advantages:

1. Rooms are cleaned in segments. This way when the robot runs out of battery, at least contiguous sections of the house are all clean.
2. Low processing requirements. The toughest computations will be: calculating the position of ultrasonic identified objects, determining if walls are connected or if there is a doorway, and choosing a path through the room to clean all open the floor space.

-Mike

Schematic V1.0

Hardware design is almost done! Here's a link to the first version of the board that will sit onboard the Roomba:

http://sites.google.com/site/zambots/project-files/MCU_boardandProgrammer.pdf?attredirects=0&d=1

Or for a less technical view, here a block diagram of the same system. Solid lines are signals and dotted lines are power connections.

And here's how it works:

1. Code for controlling the Roomba and distance sensor is written in C on a computer. This is converted into hex and sent via serial to the programmer. For this step, a serial cable must be connected between the computer and circuit board.
2. The programmer is a set of hardware the allows for programming of the Microcontroller (MCU). It must hold the high voltage (MCLR) pin to between 9 and 13.5V, and then apply a clock signal and a synchronized data stream to the PGC and PGD pins on the MCU. The data stream contains the code to be executed.
3. Once programming is done, the serial cable can be disconnected. When the programming is finished, the MCLR pin is held at 5V using a diode, and now acts as a reset switch (if pulled down to ground).
4. Power for the MCU and associated devices comes from the Roomba battery. This is an unregulated 15V, and 3 different voltages are needed on this board (3.3, 5, and 12). This is accomplished through the use of 3 voltage regulators.
• Note that during programming, there is another set of voltages on the board. This is because the serial voltages are somewhere around 7.5V, which could damage the MCU. This motivated the use of opto-couplers, so that the serial voltages and its ground (from the computer) is kept separate from the MCU voltages and their ground (from the Roomba).
5. The MCU collects distance data from the ultrasonic sensor at scheduled intervals. To do so it sends out a short pulse, and then waits to receive a pulse corresponding to the distance to the nearest object in the direction pointed. Directions will be calculated from wheel encoders, already integrated into the Roomba platform.
6. The MCU also communicates with the Roomba. This is done through the UART. First a device detect pulse series is sent. Then serial communications can be sent. Instructions tell the Roomba to use its motors, LEDs etc. or to return sensor data packages.
7. The MCU also communicates with the Arduino through the XBee module. This is done through the UART also. However the XBee operates on 3.3V, while the MCU operates on 5V. The 2 NPN transistors between the XBee and MCU are for level shifting the transmission voltages to avoid problems.
8. In order to allow both Arduino and Roomba to communicate with the MCU via a single UART, a MUX/DEMUX chip facilitates communications. 2 control lines from the MCU can select which communication channel is open for transmission or receiving.

Design is one thing, practicality is another. Hope to be testing this in the next couple weeks, and I'm sure at that point I'll make some modifications to the board. Once this is working, I plan to post my BOM too, with digikey part numbers for all the electronics and suggested retailers for the rest.

-Mike

Design Choice Consequences

Getting slightly philosophical for a technical blog here, but its fascinating how early design choices will affect future work.

For instance, you may have noted that I haven't mentioned much detail about the MCU that connects the XBee wireless module to the Roomba and grabs the ultrasound data. I've been struggling with this problem for a couple days now. The problem is that I want 2 UARTs in a single MCU, one to connect to the Roomba and one to the XBee. But I also want to be able to make my own in circuit programmer instead of buying one for a lot of money. Making programmers is fairly simple for PICs (quick google search for JDM programmer will give you some idea) but PICs with 2 UARTs are unusual and aren't supported with the normal free hex programming software like IC-Prog. Hmm.

I mentioned this to a friend today, who suggested multiplexing/demultiplexing the 2 serial lines together. Actually its a great solution, and I found it recommended on a couple sites and forums, but it has serious repercussions for my software later on. For example, imagine I want to see if the Roomba's main touch sensor is pressed. I select that channel for my TX output and send the message to get sensor data. Now I select the RX channel that comes from the Roomba, and get the sensor data. But in the mean time, if the Arduino tried to send any data over the XBee, it would get lost because the RX is demultiplexed to the Roomba not the Arduino.

As far as I can tell this means the processor on board the Roomba will have to be the Master for both channels of communication. It will have to send a message, then wait for the response (or a time-out) before communicating with the other device. There are other tricky solutions like triggering an interrupt on a rising edge generated by a serial communication on the RX line, and switching to receive from that channel but this could still generate problems if both Roomba and Arduino were transmitting at exactly the same time.

Not sure as of now what this will mean in terms of software, but I can't see it making things easier. And all because I am looking to save the cost of a MCU hardware debugger/programmer :) and make my own.

On a more technical note, I've decided on the PIC18F1320 and I'm working on designing a fun programmer that uses the on-board unregulated power supply of the Roomba instead of the tricky serial cable trick JDM uses. Less power friendly, and uses opto-couplers so I'm sure there is a fancier way, but I'm hoping to adapt it for use with a USB-Serial converter that generally won't generate the high voltages that the JDM style programmers use. I'll post results and improvements when I get some tests done. I also have a post planned that explains how the JDM programmer converts the 7.5V from a serial port into 12V programming voltages, and general programming theory/applications for the PIC.

XBee Breakout Boards and Shields

One of the first problems I noticed in my design is that XBee pin spacing is 2.00mm, instead of the common 0.100" spacing. I am hoping to do a bunch of testing on breadboards before even considering making a custom PCB, so I needed a good way to connect one XBee to an Arduino and another to on-board circuits.

First thing I looked at was making homemade PCBs. However most people suggested that while it looks cheaper, it will actually end up being similar in cost due to high losses and equipment costs. In addition, quality is generally poor, you end up needing to dispose of dangerous chemicals, etc.

Luckily I found a couple cheap solutions. Sparkfun has both a Breakout Board for XBee Modules ($2.95) for the robot side, and an XBee Shield ($24.95) for the Arduino side. Actually I found it cheaper to get both from eBay instead, though shipping times may be longer. I'll post some pictures when they arrive!

Roomba Mapping

Projects are fun. Documentation... not so much. But Zambots is science, and science requires documentation and repeatability. So here we go!

The aim of this project is to build a room mapping robot. The mechanical platform will be an iRobot Roomba. This means that once the room has been mapped, the Roomba can also clean it optimally, and without missing any spots.

To map the room, a combination of an ultrasonic sensor and touch sensors will be used. The ultrasound will create a general map, and the touch sensors will be used to re-register the robot to clear any accumulated error.

The robot must be untethered, which requires either on-board processing or a wireless module. On-board processing is possible, but I am opting to use a pair of XBee modules. This way processing can be done remotely, allegedly up to 100' away. Processing will be done mainly by an Arduino (for blog cred of course - http://xkcd.com/730/ ), though I plan to use a computer for visualization of the room being mapped.

Controlling the Roomba, once an optimal trajectory has been found, is actually easier than it sounds. The developers left a 7-pin port on the top of all Roombas expressely for this purpose :) which accept a set of simple opcodes, allowing control of the motors, LEDs and sounds as well as returning sensor data.

For those of you who prefer visual information, here is a block diagram of my proposed system:

As the project goes, I'll post pictures, videos, code and schematics as part of my efforts in documenting. Comments are very welcome, especially advice as I've never tried something this complex before.

-Mike