More than a year ago, I blogged here about using RFID to track presence times in the BORM ERP system. I used the system a lot since then. But the BlinkM was really limited as the only immediate feedback channel. To use it with multiple users, a display was needed. The default Arduino compatible displays seemed a bit overpriced, and the Nokia phone that I disassembled didn’t have the same display as I used for the spectrum analyzer. But these displays are available for a bargain from china. The only problem was that the bifferboard didn’t have enough GPIO pins available to drive the “SPI plus extras” interface. But i2c was already configured for the BlinkM.
So, the most obvious solution was to use an AtMega8 as an intermediary. I defined a simple protocol and implemented it as i2c and uart on the AVR. I also wrote a small python class to interface it from the client side. As I buffer only one complete command, I had to add some delays in the python script to make sure the AVR can complete the command before the next one arrives. Apart from that, it all worked well when testing on an Alix or RaspberryPi. But i2c communication refused to work entirely when testing with the bifferboard. Not even i2cdetect could locate the device. That was bad, since I wanted to use it with the Bifferboard, and the other two were only for testing during the development. I checked with the oscilloscope, and found out that the i2c clock on the bifferboard runs with only 33kHz while the other two run at the standard 100kHz. So I tried to adjust the i2c clock settings on the AVR, as well as different options with the external oscillators and clock settings, but I was still still out of luck. Then I replaced the AtMega8 with an AtMega168 and it immediately worked. Next, I tried another AtMega8 and this one also worked with the Bifferboard. I switched back and forth and re-flashed them with the exact same settings. Still, one of them worked with all tested linux devices, while the other one still refused to work with the Bifferboard. So I concluded, one of these cheap AVR’s from china must be flaky, and I just used the other one. Seems like that’s what you get for one 6th of the price you pay for these chips in Switzerland.
Apart from the display, I also added an RGB LED that behaves like the BlinkM before. And on top of that a small piezo buzzer. But since I could hardly hear it’s sound when driven with 3.3V, I didn’t bother re-soldering it when it fell off.
Now, my co-workers also started logging their times with RFID.
The code is still on github.
I wanted the robot arm to be a bit autonomous from the computer, and I thought the bifferboard should be powerful enough to drive it. So I wanted to install ROS onto it. My bifferboard runs debian squeeze, and that means it’s not just a matter of installing the packages as with ubuntu. There is a dedicated wiki page about installing ROS on debian, so I was of the opinion that it can’t be that hard. Actually, I once tried to install ros electric already when the bifferboard was still running debian lenny, and I ran into an infinite loop. I was full of hope that this bug had been fixed now with the release of debian squeeze and ros fuerte. But in fact, the first infinite loop was even earlier this time. And after circumventing an issue in pip with the help of a pip dev, I ran into the one I experienced earlier. I was able to find a workaround this time and reported the issue to pyyaml. The bifferboard has no FPU, and from what I can observe in python no inf and strange handling of nan. Continue reading “installing ros on a bifferboard”
With the X and Z gears propperly glued, all axes moved. But it didn’t take long for the Z axis gear to break again. The gear that came with the kit was multilayered wood glued together and laser cut. The place where the belt is, is off the axle of the stepper motor. That’s obviously not a good combination. So I ordered an alloy gear from maedler. That came without a hole in the center. I didn’t have anything else then my hand drill available. Well it’s a bit more off center then I had hoped, but nut much worse than the laser cut wooden gears. And still, it works. So, all three axes work now. The ammount by what they move doesn’t seem right, so I’ll have to adjust some parameters still.
Continue reading “RepRap part 3: Ethernet connection”
Before I discovered what my Bifferboard really is, I almost disposed it, but now It found a new purpose. It’s a networked rfid Terminal for time tracking on our BORM ERP. I use a simple python script on the device because it’s easier to experiment on a device where I would rather not compile too much every time trying something. In fact, this is my first python project appart from looking through some scripts and changing a few lines here and there.
I used a nas dongle from ARP for a while to share an USB harddisk, and I always wondered about what’s inside. It’s a nifty little device that works reasonably well. It needed a reboot from time to time, and it had some issues with the filesystem. Because of the FAT filesystem it couldn’t store large files, but what I missed most was ssh. Not ssh itself, but scp, sftp and rsync. I knew that without further information it would be impossible to add these. But so far I couldn’t find out anything on the internet. Then somehow I found a blog post with a device that looked similar from the outside but was sold more like a hacker device. So I went to figure out if it’s the same. It looked similar from the inside as well. So, it is probably really a bifferboard. The pins for the serial console matched, which was even more proof…
The boot messages with the stock firmware look like this: $ minicom -b 115200 -D /dev/ttyUSB0
Continue reading “Running debian on a nas dongle [updated]”