Solution to "cannot find -lpololu" and a question

Hello everyone, I’m Tomo. I couldn’t see an introductions section so I’ll jump straight in with a solution to a problem and a question:

I downloaded AVRStudio 4 and the Pololu C/C++ Library today and have spent a very frustrating hour trying to get the first example program to compile - including un-installing everything and building libpololu.a from source. I kept getting a linker error saying that -lpololu couldn’t be found.

I’ve solved the problem so I thought I’d share by way of an introduction. The libpololu.a file needs to go into C:\WinAVR-\avr\lib NOT C:\WinAVR-\lib, which the online instructions seem to imply. Dunno if it’s been solved previously, of if I’ve been a bit thick; the search function here says that -lpololu is too common a word to search by :slight_smile:

My area of interest here is behaviour based robotics. I have an AI system I’ll be implementing on the Orangutan LV-168 I have on order, so I really need to go to assembler. I was once an experienced assembler programmer so there’s no help needed there, but I’m keen to get some code running. My question: is there a guide available for writing assembler in AVRStudio 4 for the LV-168?

Hi Tomo, welcome to the forum. We’d be happy to hear where you are from and what you are planning to do with the LV-168. To introduce yourself better, feel free to post a more detailed description of your project in the “Robotics Projects” section of the forum, put information about yourself in your profile, etc.

Thanks for the note about the AVR library - I know it’s confusing that you have two lib directories (and also two include directories!) on your system, but I obviously wasn’t clear enough about it. I’ve updated the page with a few more sentences to make it easier for future users. Just so you understand what’s going on, the files in the avr directory are specific to the AVR, but you have other C libraries on your system that are necessary for programs running on your PC - these are compiled for the PC and are not compatible with the AVR, so they are kept totally separate.

I think Ben will post with some more information about assembly, but your claim seemed strange to me - why would wanting to do AI imply that you need to use assembly? If anything, I would expect that a high-level language is a good place to implement high-level concepts. But AI is a very general term - can you tell us more about your plans?

Hello, Tomo. There is no Orangutan-specific guide to writing assembly for the ATmega168. I recommend you look at some of Atmel’s documentation on the subject:

AVR Instruction Set
AVR Assembler User Guide
AVR034: Mixing C and Assembly Code with IAR Embedded Workbench for AVR

Another approach you can try is using AVR Studio’s disassembler to look at the assembly code generated by the compiler from your C programs (alternately, you can configure your project to generate a list file that will show your program as a set of assembly instructions with the corresponding C code as comments spread throughout the file). This could help you get familiar with assembly for the mega168.

- Ben

Thanks for your help and I’m happy to try to explain what I’m trying to do.

I grew up in the UK in the late 1970s and learned to program in assembler at school during “A” level computer science, and at home on my old ZX81 and Spectrum. My second job was spent writing real-time data capture software in 6502 on (of all things) a BBC B Micro. I thoroughly enjoyed programming in assembler, but times were changing quickly, PCs and Windows took over and I spent 20 increasingly miserable years in the computer industry. For the past five years, I’ve been making my living as a freelance technology writer (and writing books for macgicans - don’t ask).

Earlier this year I was putting together a feature about homebrew computer builders (guys who’ve literally designed their own CPUs from scratch, then sat down with the relevant 7400 series ICs and created something I personally find astonishingly cool.) I started wondering whether it’s possible to go a bit higher level than a bag of TTL chips. The logical choice was microcontrollers. I stumbled on the Orangutan, saw the facilities it offers, thought “Oh my God, it’s assembler time!”, and started wondering about building something “interesting” with it.

My first thought was to create a neural network and have two buttons - for praising and chastising the unit – and have it learn whether it’s doing the right thing to its outputs when it encounters certain patterns of values on its inputs. Then I thought about using data structures to hold abstract information about the machine’s state, rather than simple data. Instead of a neural network, code would deliberately change the “activation” levels of each of these structures depending on the current combination of inputs. It would then test for certain combinations of activation levels and decide what to do to the outputs.

Here’s a simple example: supposing one data structure determines how “bold” the machine is (how far it moves each time), it would normally hold a certain value as its activation. Now suppose that the code running the motor ports uses that activation value to time each burst of movement. Supposing the machine is programmed so that darkness makes it slowly decrement the structure’s activation value over a few seconds. The effect would be to to cause the robot to progressively grind to a halt. Conceptually, the machine could on some level be said to become “fearful” of moving the longer it spends in the dark as a defence mechanism. At a certain threshold of fear, it may also be programmed to turn on a high power LED headlamp. This would have the effect of increasing its boldness again by it detecting the presence of light and removing the inhibitory effect.

Now, supposing the device encounters the family cat, which decides to press robot’s front bumper repeatedly. If the unit is programmed to also become less bold when it’s bumper strikes something, it will gradually “play dead” due to the increasingly inhibitory effect repeated bumper pressing has on it. If the cat continues, the fear threshold triggers, the headlamp snaps on, the inhibitory effect is lifted, and the device rushes forward in a display of apparent aggression - different context, different meaning. If the cat is playing with the robot in a room sufficiently dimly lit for the unit to feel the inhibitory effect of the gloom, two inhibitory effects will be acting on its state, and it will stop faster.

By making inhibitory effects transitory, the robot would gradually move again of its own accord if the cat were to walk off and leave it motionless for long enough, and may overcome its fear of the dark in some gloomy places rather than stop, but it would still stop to turn on its headlight in complete darkness. Imagine what you could do with a few more of these structures coding information about other aspects of the robot’s state. How about some gradually increasing or increasing in value to indicate a state that changes over time - like loneliness or boredom.

It’s the possibilities for emergent behaviours like these and a minimalist approach to the hardware that interests me. I need to pack a lot into 16k, I’m completely comfortable with assembler, and having 20 MIPS all to myself sounds great! I’ve studied the instruction set and how the unit functions (both look very nice indeed), I have a data model worked out, the first cut of the main duty cycle code designed, and the Orangutan LV-186 looks exactly what I need to get started. I love the idea of EEPROM. It looks like backing store to me, for the robot to store a persistent “mental state” between runs. I’ve also have some weird ideas for passive sensors but they’re less well defined at the moment. So, I’m basically looking forward to “tapping on tin” again, and packing as much into 16k as I can, just like the good old days :slight_smile:

Does that make any sense?