Atmel Atmega1284

I started tinkering with the Atmega1284. Among other things it gives you an expansive 16kb of SRAM, 2 uarts and of course looking at the chip a bunch more IO. A huge plus is that you can get a nice small SMD version and this 40 pin DIP monster with the same 1284. Yay for breadboard prototypers who don't oven bake each board configuration! The angle of photo seems to include the interesting bits. Just ignore the two opamps on the far right :)

I had trouble getting this to work with a ceramic resonator. The two xtal lines are right next to each other with ground just above but the 3 pins on the resonator were always a bit hard to get into the right configuration for these lines. Switching over to a real crystal and 22pF caps I got things to work. The symptoms I was having with the resonator included non reproducibility, sometimes things seemed to upload sometimes not.  Also, make sure the DTR line is going though a cap to the reset pullup resistor. See the wiring just to the right of the 1284.

I haven't adapted the Arudino makefile to work on this yet, so unfortunately I still have to upload programs using the official IDE. I have the makefile compiling for the 1284 but das blinken doesn't work when I "make upload".

3d printed part repo for attaching to Actobotics structure

I started a github repo for 3d print source files to attach things to Actobotics structure. First up is a mount to secure a rotary encoder directly to some channel as shown below.

As noted in the readme, I found a few issues post print, so had to switch to subtractive modelling (dremel time) to complete it. I leant a few things from this though so the issues are less likely to bite me in the future. There are some comments in the scad file so hopefully it will be useful to others and maybe one day I'll get a PR to update it. The README file in the repo will probably be the one true source for update info and standing issues with each scad file.

You can just see the bolt in below the rotary encoder. That has a little inset in the 3d part to stop it from free spinning when you screw in the 6-32 nut from below the channel.

Arduino and wireless networking

The nRF24L01 module allows cheap networking for Arduinos. Other than VCC which it wants at 3v3 it uses SPI (4 wires) and a few auxiliary wires, one for an interrupt line. One of the libraries to drive these chips is the RF24. Packets can be up to 32 bytes in length, and by default attempts to send less than 32 bytes result in sending a whole 32 byte block. Attempts to send more than 32 bytes seem to result in only the first 32 being sent. There is a CRC which is a 2 byte and is on by default.

For doing some IoT things using a HMAC might be much better choice than just CRC. The major advantage being that one can tell that something coming over a wireless link was from the expected source. Of course, if somebody has physical access to the arduinos then they can clone the HMAC key, but one has to define what they want from the system. The HMAC provides a fairly good assurance that sensor data is coming from the arduino you think it is coming from rather than somebody trying to send fake data. Another rather cute benefit is that the system doesn't accept junk data attacks. If your HMAC doesn't match the packet doesn't get evaluated by the higher level software.

Using a Sha256 HMAC the return ping times go from 50 to 150ms. The doubling can be explained by the network traffic, as the HMAC is 32 bytes and will double the amount of traffic. I think perhaps the extra 50ms goes into hashing but I'll have to measure that more specifically to find out.

Once I clean up the code a little I'll probably push it to github. A new RF24HMAC class delegates to the existing RF24 class and sends a HMAC packet right after the user data packet for you. The interface is similar, I'm adding some writenum() calls which I might make more like nodejs buffer. Once you have added the user data packet call done() to send everything including the HMAC packet.

RF24 radio(9,10);
RF24HMAC radiomac( radio, "wonderful key" );
radiomac.beginWrite();
radiomac.writeu32( time );
bool ok = radiomac.done();

The receiving end boils down to getting a "packet" which is really just the 32 bytes of user data that was sent. The one readAuthenticatedPacket() call actually gets 2 packets off the wire, the user data packet and the HMAC packet. If the hmac calculated locally for the user data packet does not match the HMAC that was received from the other end then you get a null pointer back from readAuthenticatedPacket(). The data is either authenticated or you don't get to see any of it.

RF24HMAC radiomac( radio, "wonderful key" );
uint8_t* packetData = 0;
if( packetData = radiomac.readAuthenticatedPacket() )
{
     int di = 0;
     uint32_t v = readu32( packetData, di );
     got_time = v;
     printf("Got payload %lu...\n\r",got_time);
}

Oh yeah, I also found this rather cute code to output hex while sniffing around.

TerryTorial: Wheel Feedback, Object detection, Larger size, and now a screen!

Terry the robot now has grown up a little, both semantically and physically. The 12 inch channel that was the link to the rear swivel wheel now has many friends which are up to 15 inches higher than the base beam. This places Terry's main pan/tilt camera at his top a little bit above table height, so he is far more of a presence than he used to be. On the upside, the wheel controller, shaft encoders, and batteries can all live on the lower level and there is more room for the actual core of Terry up top. I'm likely to add one or two more shelves to the middle of Terry for more controllers etc.

There is now also a 16x32 RGB matrix screen up front so Terry can tell you what he is thinking, what speed his wheels are rotating at, and if there is an obstacle that has been detected.

I'm rendering the framebuffer for the screen on the BeagleBone Black using Cairo and Pango (thus & freetype). The image data is extracted from Cairo as 32bit RGBA and packed down into planar data that the arduino expects. That packed framebuffer is then sent over UART to an Arduino 328 which takes care of refreshing the RGB matrix so that fake colour levels are achieved using a software PWM/BAM implementation. Yay for the BBB having 4.5 UARTs. I need to work out how to bring up the TX only UART as that is perfect for the one way communication used to drive the screen.

I should be able to get better colour precision using a Teensy 3.x as the screen driver. The Cortex-M4 just has more cycles to be able to softpwm the screen faster to be able to get a greater perceived colour range.

I customized the font a little in FontForge. Specifically I modified the kerning for "Te" to not waste as much space. The font is based on Cantarell by Dave Crossland. I've only just started on this open font to LED matrix stuff, but with some form of PWM and FreeType rendering the data I hope to be able to get nice antialiased font renders, even at the low resolution of 16x32.

The wheel encoders make a huge difference to the whole experience. Even without full autonomy the encoders allow you to have a repeatable oval or patrol path which can be followed. Also being able to setup the speed to avoid large acceleration or jerky movement so that the higher Terry is still a very stable Terry when on the move.