Check out the new projects site for A-i-S

Tuesday, November 11, 2008

tighten the hatches for the on coming storm

Ok, so it seems my Servo code is actually working, just need to ensure the right values are being sent to ensure the sweep.

Also need to determine the exact right sequence to send to ensure reliable comms - ie how many '\n' should I have.

Next step in debugging is to ramp up and down the servo values.

Monday, November 10, 2008

We are not alone and neither are daughterboards

Well in an effort to use Doxygen and sweep sensors I have come to the conclusion that I need to revisit my previous motor control code.

Specifically I need to drop or slow down or generally tweak the "randomness" of the forward motion watchdog timer. [This monitors how long we have been travelling forward and compares against a random value - this value is too short at the moment].

On another topic I think I will obtain a Tamiya Hornet to modify into a robot base for GPS playtime.

It has a ESC and nice suspension and is a good base with it's bathtub chassis. I propose to control the servos with an AVR of course (unless I fully flesh out the NGW100).

Sunday, November 9, 2008

Nothing is forever but it sure feels that way sometimes

Well I am back into the saddle after a long time when I was forced to focus on other things.

Back into getting 'Think-Tank' some more smarts. Big issue was just to get 'Think-Tank' back to moving and shaking.

It seems the first issue was getting enough juice to the Mega32 - the Brown Out detector was tripping each time I fired up the motors. I'll have to investigate where to put some more caps in addition to those already.

The other issue was task priority. It sprung to life after dropping the priority of the 'Think' task. I think I may have screwed up the portTick value for the delays and Think was firing too fast and as it was top priority, didn't give anyone else a chance.

Hopefully I'll get some time soon to start delving into Think-Tank's mind again soon.

Monday, August 25, 2008

Separate the light from the dark....

Well I decided that it is high time my robot can see the world for what it is.....or at least for what 4 LDRs setup on voltage dividers can reduce to a voltage range picked up by the AVRs built in ADCs :P

Using LDRs that I think I got from Futurlec I soldered a 100k ohm resistor to one leg. Now if you apply 5V on the free leg of the resistor, zero (Ground) on the free leg of the LDR you can read a reliable 0.7V to 4.2V range from GND to the soldered leg of the LDR.

Now I am going to put them on a Servo facing away from each other. With 180 degrees of servo rotation, I can rotate sensors to calibrate from each other's readings (assuming the environment doesn't change the light conditions in between servo movements.

More tomorrow....

Thursday, August 14, 2008

When at first you don't succeed, try a thousand more times

Ok, so I am going quickly insane here.

I have a DS1307 (RTC) which has a perchant for I2C (TWI) and Packed BCD. I have set up a nice I2C routine to speak to it and receive back information such as time (hours, minutes, seconds etc).

All looks ok when you feed in 0,0,0 but when I feed in 0:59:30 and wait for it to hit one minute, it then wraps to 0:40:00 and counts up from there.

I have checked the data going in and out and have no idea....

Anyway I left that for a moment and decided to update the code that receives servo position commands on my MEga168V board on my robot. I implemented the cmdline demo from Procyon and it worked flawlessly.

Now I can send "servo 1 75" and it will send servo 1 to the 75% mark. All good I say.

Wednesday, August 13, 2008

Bestill my beating silicon heart

Ok, here is a neat C function for converting BCD to Binary:

uint16_t bcdtoi(uint16_t bcd_number)
uint16_t integer;

integer = ((bcd_number&0x000F) >> 0) * 1;
integer += ((bcd_number&0x00F0) >> 4) * 10;
integer += ((bcd_number&0x0F00) >> 8) * 100;
integer += ((bcd_number&0xF000) >> 12) * 1000;

return integer;
If you only want to deal with 8 bit numbers then feed in 8 bit variables and comment out the last two lines inside the body.

I have used this with the AVR Mega32 to ead in input from a DS1307

Tuesday, August 5, 2008

A moment in time

I've decided to use the Procyon wrappers of the TWI implementation.

I've struck an issue that the procyon code didn't compile once I linked in the i2c header. So now I am running a test project to ascertain a known good implementation to carry into my bot's code.

Monday, August 4, 2008

You take the high road, I'll take the side track

Well today I tried to get the DS1307 working but to no avail.

I was trying to reuse the code used to drive the IR sensors but it doesn't have everything TWI/I2C needs.

The solution? Implement the avrlibc version of twi and follow the examples. Hopefully I will be able to do this tomorrow night.

On a side track my Arduino does everything is says it could, very interesting and polished little performer.

Sunday, July 20, 2008

The dawn...

Today I set up the Mega168v Board to control the servos.

I also remounted all the boards to be more secure.

I also switched in 4xAAA for the previous 4xAA battery pack to lower the centre of gravity.

Tomorrow I hope to look to the Procyon "cmdline" example to receive UART input properly using Procyon.

I suspect I will attach my own function to be a handler for when UART data is in the UART buffer.

Wednesday, July 16, 2008

Channelling Mother Earth

Seems I have a problem with the Earth.....the Earthing of my bot that is.....

At first glance the dodgy connection on the UART is causing it but I think that is a smoke screen for an earthing issue elsewhere that is related to the Mega32 reset pin not letting it start up on occasion (especially when the ISP head isn't plugged in to control the reset pin).


Apart from that, tonight I've started implementing better collision avoidance. I'm using random numbers between 0-9 to determine what behaviour to implement when an obstacle is detected.

I chose to use a range so that I could weight the probability of which behaviour occurred as well as have the resolution in decision making to add new behaviours (like a little bit left, bit more left than that etc etc).

That is the plan, I am sure I'll need to iron out a few bugs before it works as expected.

Sunday, July 13, 2008

The machinations of thought

Well my machine can think.....sort of.....

I got the re-worked code to operate satisfactorily.

Using FreeRTOS tasks I've created a modular set of code for my bot. Every 300ms the sensors are checked, every 400 the motor driver board is updated and every 300 ms the main "thought" logic is applied.

Yes so far I have 3 FreeRTOS tasks running, the maximum for a Mega32 is said to be around ten.

I do have an issue with portTICK_RATE_MS which is only kludged at this stage. I still don't quite get where this MACRO is set and how. I am using it to convert from CPU ticks to millieseconds and from what is coming out on UART I'm guess the MS calculation is about 50% slow. I changed configTICK_RATE_HZ to 1000 from 200 but I'm still unsure exactly what this effects. (Note I have set the correct clock rate of 16Mhz so no errors should be coming from there).

Oh well, time to put it to one side and do something else this evening, I've cleaned up the code, documented it, extended it to about 600 lines in the main program (up by 200), ironed out some logic bugs and ensured the glue logic to motors and IR sensors works as expected.

All in all quite a good effort, accelerometer to be next or maybe just proper collision avoidance and handling.

Note about FreeRTOS tasks

Just a quick about FreeRTOS tasks.

Don't forget that if the highest priority task runs wihtout a delay in it, it will stomp all over any lower priority tasks.

Saturday, July 12, 2008

Return to normal scheduling...

Well I got back to coding for my "Think tank" today (Think Tamiya track base with a Mega32 on it).

I was happy with the functionality of the code when I left it previously. I had included FreeRTOS to create tasks to drive and poll distance sensors. So today I decided to clean the code up considerably and document it properly.

Now I've done that I'm able to start implementing "behaviour". This will be the task for tomorrow. I also hope to implement the tilt sensor tomorrow.

Still not sure how I'm going to create the code for the servos just yet. FreeRTOS seems pretty happy at the moment so I don't think I'll tinker with FreeRTOS' timer code. I'll have to play with Procyon's timer code or just write my own from scratch. This decision will be influenced by how many servos I think I will end up controlling. I actually think I'll create a "daughter board" which acts on UART commands to control servos.

BTW having a 19" monitor on my development machine is so much better than the old 15". I am not squinting as much and can actually see all of AVRStudio in one view :)

Arduino bandwagon - I'm on it...

Ok every man and his dog is talking about the AVR based Arduino platform. Admittedly I haven't played with this yet but have seen that it is a) Easily to use b) Truly open source.

So with that in mind I thought what the heck and ordered an Arduino Decilima (sp?) from Little Bird Electronics today. A bit pricey but there are in Australia so hopefully it won't take too long to arrive.

Rs Media and friends

Well a couple of weeks ago I was at the DJ's outlet store and saw RS Medias on sale for $150 so I grabbed one.

I haven't looked into these or similar Robosapiens before. I did like the fact that it had a Linux OS proudly proclaimed on the box but didn't like the fact that when I got home, I found that they had failed to release meaningful source code.

I have also had issues getting the software to work on Windows 2K or Vista. I'll try XP when I get a chance.

A further annoying thing is that there was a proper SDK released at a Java trade show a while back but the SDK was not released to the public. There is talk that maybe they will release it. This is tantalisingly annoying - there is a CD out there that lets you play with the VGA camera, microphones, and bipedal motion but you can't buy / beg /borrow or steal it.


Apart from that, it is pretty amazing - does chew through the batteries pretty quickly though.

Monday, June 23, 2008

Oh the trickery.....

Ok this morning was more about setting up SAMBA and sharing printers than AVRs...

Anyway the challenge today is to conrtol a servo whilst using FreeRTOS on a AVR ATMega32. The trick here is that I usually the Procyon library to control Servos (easy to include, easy to address several servos etc etc). Unfortunately I can't include the timer.h from Procyon and the FreeRTOS headers. The issue seems to be a conflict over the timer interupt.

The Mega32 has two 8-bit timers and a single 16 bit timer. At the outset, I'm assuming tht FreeRTOS uses the 16-bit timer in the demo code I have modified.

I can see several possible ways forward...

1) Manually set up servo control without using interrupts

Probably a silly idea because then your cpu will spend most of its time counting numbers up rather than something useful

2) Alter FreeRTOS to use a different timer than referenced in timer.h

Looks to more trouble than it is worth considering the complexity of FreeRTOS. Best to avoid if possible.

3) Avoid clashing with FreeRTOS and its choice of timer. Choose a timer and interupt it does not use and use this timer instead

I think this is the first path I will attempt. Hopefully I will find an available 8-bit timer and create the code to drive the few servos that my bot requires.

4) Setup a servo control board and send UART signals to it.

If 3) above fails will take the next easiest road and build a small separate board to control the servos and control it via UART. This may have a negative impact on control and feedback though.

Sunday, June 22, 2008

Slow news day

Well since I got to the point of having FreeRTOS working I haven't felt the need to push ahead quickly on my carpet rover.

The next step is to write some from scratch code to control the servos. I can't use Procyon Library routines without have to modify the header of timer.h - interrupt #7 gets stomped by both timer.h and FreeRTOS's header files. Instead of creating potentially unstable situations, I'm just going to write my own servo code and leave FreeRTOS alone.

OT: I've been cleaning up "the lab" - got to the point were I can vacuum it even! Otherwise been engaged with seting up new WRT54GL Wifi router with WPA security and then configuring 2x eee pcs, brother's PC's wifi, and sister's Palm TX with wifi.

Being able to make custom Cat5e "in-house" proved a boon for setting up the Wifi router in a nice location.

I've been playing with the eee pc a lot - nice machine with a decent distro - once you set up a few more repos the think is easy to play with - picasa / ff3 etc etc. A certain owner of one of them is forming an addiction to Frozen Bubble!

Wednesday, June 18, 2008

AVR FreeRTOS troubles

I have been playing with FreeRTOS ( in an attempt to equip my carpet rover with the necessary intelligence to do two things at once.

I am developing my FreeRTOS solution on a AVR Mega32.

Last night I attempted to create two "tasks" to run in unison. Unfortunately despite my best efforts, after one iteration of each routine, one of the other routine would then be executed ad infinitum.

I am unsure why this happens. Tonight I will start debugging by executing two simple routines. I wonder if it has something to do with FreeRTOS "Queues". I have searched but been able to determine their exact purpose.

I'll be further looking at the AVR demo program to assist in debugging.

UPDATE #1: Ok it seems if both tasks are just outputing UART then they both work well together. Now lets see if I can incorporate the I2C (TWI) code for the IR distace measuring sensors.

UPDATE #2: Ok got it working without Queues. It actually seems that all I needed to do was a make clean and then a make all as well as comment out the #include for "timer.h" which wasn't used anyway.

Adventures in Silicon

So what is this blog about I hear you say? Will it haves photos of cute cats? Will it reproduce the latest shipment of fail that has hit my inbox? Will you be able to read about my travels in the Greek Isles?

..."No" to all of the above. I hope this blog will serve as a notebook of my hobby relating to robotics and microcontrollers. The primary focus will merely to be documenting for myself what I am doing, if anyone else cares to read it, so be it.

Oh and my apologies for anyone who came to "adventures in silicon" thinking it involved large breasted women and not the silicon wafers microcontrollers are made of!