avrdude 6.0.1, avr-gcc 4.8, and keestux Eclipse AVR Plugin 2.4.1

Posted on October 26, 2013 by feilipu

Always looking for the latest and greatest code for AVR, I scan the debian Sid repositories every few months for updated packages to use. Recently debian Sid included the latest gcc-avr 4.8 package, binutils-avr and the new avrdude 6.0.1 package. So I had to install them all to test.

Updated and Local

The new avrdude 6.0.1 is the first release in two years, so it has a lot of good stuff, including a fix for the long standing chip delay bug affecting the AVRmega1284p used in the Goldilocks and Pololu SVP platforms.

Unfortunately, there is a new device format used in the avrdude.conf file which breaks the standard Eclipse AVR Plugin, rendering the MCU choice ineffective.

Asking a question on avrfreaks.net found the answer. keestux has fixed the problem and has released an interim AVR Plugin 2.4.1 which incorporates a fix for the change in avrdude.conf file format.

keestux Eclipse AVR Plugin 2.4.1 is at: http://www.ijzerbout.nl/avr-eclipse/updatesite

Add his update site to your software sources, and life is good again.

Dogbot – Post 6 – Back on (PID) track

Posted on May 2, 2011 by feilipu

Exactly a year has passed since my last post on the Dogbot. I ended up getting very frustrated with my inability to get sensible odometry out of the Pololu Encoders using the Orangutan SVP auxiliary processor, and needed to put the project aside for a while.

I believe that I spend a good few weeks digging into the code, to see why I wasn’t getting sensible readings from either, or at times both, of the sensors. Then I gave up, and took up an easier challenge being learning PWM control, and started building the Retrograde Clock.

Recently, I picked up the Dogbot again, and determined that I would make it work. I worked out that one of the Encoders was not right, using my excellent new Seeedstudio DSO Nano. So, then I ordered a new Encoder. At the same time I ordered a new chassis for Dogbot, as the old one was damaged by my cleaner, and decided to replace the medium capacity Liquidware Backpack, used for driving the motors, with a high capacity variety.

I took the opportunity to rebuild the dogbot onto the new chassis, and to simplify the system to make it more robust. One construction change was to use the Wall Plugs as a flexible structure, and screw into their ends, rather than using them as a spacer with a bolt through the middle. This allowed me to use the ends of the wall plugs as mounting points, because they could be fastened tight. Previously, because of the angles, they had needed to remain relatively loose.

I have removed the rear mounted PIR sensor at this stage. It is easy to add again, at the appropriate time.

Following reconstruction, I found that the Encoders continued to give unusual (wrong) results. Finally, I looked into the details of the encoder outputs again, using the DSO, and realised that their outputs really NEED to be exactly tuned, using the tiny pots, to 50% duty square waves, otherwise the Orangutan SVP cannot get an accurate count. With this fixed, then the Odometry was built up accurately, measuring the count to travel a fixed distance. With this figure, the actual diameter of each wheel can be calculated, and hence the travel required to go in a straight line.

It is important to note, that Dogbot doesn’t go in anything like a straight line, with full power applied to each motor. The friction, and wheel size differ enough to make it curve quickly from the straight and narrow. So PID is absolutely necessary to keep it running straight. With PID implemented properly then, finally, Dogbot runs straight.

These photographs are taken with the display indicating two items. On the top line, the target distance, represented in x and y distance to travel, is noted. Also the deviation from correct heading to target. The instruction is requesting Dogbot to travel 50cm along what it has been told is the x dimension. The instruction is also implying that the Dogbot is initially facing in y direction, and needs to rotate its poise 90deg clockwise to face along x, before it begins its travels.

The code is set up to all allow specification of an initial poise, and a final poise, as well as x and y distances to travel, for the Transport Task to undertake.

The bottom row of the display shows the distance reading indicated by each of the three sensors across the front of Dogbot. Central indication being the I2C ultrasonic sensor, which is very accurate, but not at all directional. Left being the long range IR sensor, and Right being the medium range IR sensor. These sensors are very directional and can differentiate a thin rod or edge of a hand placed in front of them. Combination of these sensors will enable Dogbot to travel safely in a forward direction.

Not displayed is the output from the I2C thermal sensor. It has been tilted back, so that its vertical array of 8 pixels is looking up from +5deg to +70deg. It can see very small differences in temperature from ambient, which it also reports.

At this stage my work continues to get the Dogbot to consistently travel from one location/poise to another location/poise. Whilst I have the code in a state that it can achieve this, it doesn’t yet do it consistently, because of variables in the drive system that need to be properly tuned. And, I could improve the code a lot too. The code is a bit amateurish.

Notes to photographs

Liquidware battery packs have a on/charge switch that effectively isolates the battery. This has proven useful, as I can turn the motors off, whilst still programming the Orangutan SVP. Not designed, but in hindsight very useful.

To counter sagging voltages, and noise on the supply lines, I have fitted 1uF Tantalum capacitors on all of the sensors. This helps to ensure that they are getting a good supply when they are firing.

Both Thermal array sensor, and Ultrasonic distance sensor are canted up to get their cone of vision away from the floor. I have left the IR distance sensors facing parallel with the floor, as they don’t get false readings from the floor (assuming it is flat), and I don’t want to miss low objects that might interfere with the Dogbot.

I added the fishing weights to the rear of Dogbot to ensure it had good balance. It has sufficient weight to rear from the batteries to stand up properly, but when braking it is quite top-heavy. So, the low heavy weight at the rear helps to ensure that it doesn’t tip over.

Although there are no other items on the motor circuit, I have added some 1nF bypass capacitors on the motors. Can’t hurt.

It is alive. Here the IR glow from the sensors has been captured by the camera. Perhaps Skynet lives?

My next steps are to finish the Transport Task so that it can reliably go from point to point. Then, I’ll integrate more information into the Transport task from the accelerometer sensors, to improve directional accuracy. Then to build some mapping code to allow obstacles to be located and avoided.

Freetronics freeRTOS Retrograde Real Time Clock (DS1307) – Part 3 Final

Posted on July 30, 2010 by feilipu

In Part 2 I promised to build a very stylish finished product, that could be displayed with pride. Well, I don’t think I’ve quite achieved that. But, at least now I consider the project finished, and now have the confidence to get on with other projects.

I have mounted some tiny servos, the funky white on blue LCD display, and the Freetronics 2010 board on some Craftwood. Cutting the hole for the LCD was a bit hit & miss, using a carving knife to shape the hole, and managing not to loose any fingers in the process.

The hour servo is mounted at the bottom of the board, and travels clockwise from midnight, with noon vertical, until it re-tours to 0 on the stroke of midnight. The hour hand travels clockwise from 0 minutes at the bottom, over 30 minutes horizontal, to 59 minutes at the top of the stroke. At 0 minutes, the minute hand re-tours to 0 at the bottom. I find the movement of the servos on the stroke of the hour somewhat like a chime. Not too oppressive, but enough to draw my attention to the passing of another hour.

As the 4 line LCD has so much screen real estate, I have added the maximum and minimum temperature display, with hour, day and month when each extreme was reached.

Adding the LM335Z Temperature IC was discussed in Part 2. I found that the accuracy of the LM335Z IC could be improved by firstly knowing exactly what the Vcc was for operating the AVR device. Measuring this, and putting it in the calculation enabled enough accuracy to be found. Using the 5V regulator on the Freetronics 2010 delivered 4.97V for me, and this value is hard coded into the code. I have several LM335Z devices and they have different offsets, which is adjusted by modifying the subtraction in the Kelvin to Celsius calculation. As the LM335Z is accurate once the offset is established, there is no need to operate it in the “accurate” mode, IMHO, given we have software to make the adjustments it needs.

The instability in the temperature readings discussed in Part 2 was caused by the long wires to the sensor. Once the device was fixed into the prototyping area on the 2010, together with bypass capacitor, the stability of readings improved greatly. However, during testing, I noted that the maximum values were reading very high. These false high maximum values were caused because the ADC process was sampling during a servo move. The servos consume a lot of power, and this causes voltage drop on Vcc. Hence the reference voltage for the ADC is no longer accurate.

To prevent the ADC from operating during the servo moves, I simply used one of the freeRTOS semaphores I established previously. I use semaphores to control access to the LCD, the I2C and to the ADC. Use of a semaphore enables independent processes to share a single hardware resource without conflicts developing. The fix for the erroneous high maximums was done simply by taking the ADC semaphore (to prevent the ADC reading process from starting) during times when the servos are being instructed to move. Simple, with freeRTOS to manage the process interaction for me.

ERRATA

The code included in the updated source does not properly fix the issue of false maximum temperatures. It incorrectly releases the ADC semaphore immediately following resetting the PWM values. This means that the hands can still be moving when the ADC process gets unblocked which causes false maximums, because of voltage droop in Vcc, typically at midnight when both hands are in motion.

The fix is to move the vTaskDelay call between the set_PWM_hardware and xSemaphoreGive calls. I also increased it to 2000 milli Seconds too, to ensure the hands are really stopped before the ADC process gets unblocked.

set_PWM_hardware( servoHours_uS, servoMinutes_uS );

vTaskDelay( 2000 / portTICK_RATE_MS ); // a 2 second delay to ensure the hands have properly stopped.

xSemaphoreGive( xADCSemaphore );

END ERRATA

Another piece of code added since Part 2 is to write the maximum and minimum temperatures and the times the extremes occurred into the EEPROM available on the 2010. The functions to use the EEPROM are available in the AVR library and are very straightforward to use. Having a permanent record of temperature extremes is perhaps one thing this clock does, that other clocks in my house can’t do.

There are a lot of comments in the updated freeRTOS Retrograde Clock code, now hosted at Practical Arduino. As a reminder the code uses the AVR and Pololu Libraries, so these both need to be installed before you compile.

Freetronics freeRTOS Retrograde Real Time Clock (DS1307) – Part 2

Posted on July 7, 2010 by feilipu

Part 2 of this project involved learning how to use hardware PWM to control servos. And, then to make the clock actually work with retrograde analogue hands.

First the functional definition. A retrograde movement in horological terms is where the indicators or hands spring back to their home or 0 position at the end of their cycle. So for a minute hand, after 59 minutes and 59 seconds, its next movement would be to reverse move to home at 0 minutes. For the hour hand this could happen after 12 hours or 24 hours. 24 hours is the case that I have chosen to implement. The idea is to have the hour hand trace out a day from sunrise in the east, to vertical noon, and to set in the west.

In part 1, I added the servo headers to align with the Arduino Digital Pins 5 & 6. These pins are driven by the Timer 0 PWM hardware. Following quite a few evenings trying to understand how to generate PWM using the hardware (OK, I’m a bit slow), I realised that it is not very easy to get a good servo signal out of Timer 0 or Timer 2.

To generate the right signal for a servo, you need to produce a pulse every 20mS (50Hz). The width of the pulse should be 1.5mS to get the neutral position. Depending on the servo design, pulses with width from around 0.8mS to around 2.2mS (repeated every 20mS) will drive it to either end of its range. Depending on the servo, 0.8mS may drive it clockwise or anticlockwise. I have both in the clock. For example, the “hour” servo goes clockwise with a wider pulse. The “minute” servo is the reverse case.

The main issue with Timer 0 and Timer 2 is that they are 8 bit timers, counting to 255 before resetting to 0 (ideally after 20mS). Since the required pulses are between 0.8mS and 2.2mS, there are only about 12 “positions” available for the servo to take. Not enough to allow a minute hand to indicate 60 different positions.

Therefore it became clear that, for this application, it was only possible to use the 16 bit Timer 1 to control the servos.

Setting up Timer 1 is relatively easy, once that decision had been made, so the code was implemented. But, this meant that I had to reconnect the servo headers to Arduino Digital Pin 9 and Pin 10, which are driven by the Timer 1 PWM hardware.

Also, in the pictures below, I have added a header to allow power, LCD backlight (32Ohm), and contrast (1kOhm), connections to the standardised HD44780 LCD.

Ok, so here’s the issue. I’m using the Pololu Libraries for writing to the LCD, and the standard connection for the data line 4 on the HD44780 LCD goes to Arduino Pin 9. The same pin I need for the Timer 1 PWM. Ouch.

Modifying the library is not too difficult. We can move the Data line attached to Pin 9 onto Pin 11, and all is well. This is done in the following file.

~/libpololu-avr/src/OrangutanLCD/OrangutanLCD.h

The changes are noted in the #define lines below

#define LCD_DB4                PORTB3        // Was PORTB1. Use PORTB3 to avoid the Timer1 pins.
#define LCD_DB5                PORTB4        // PB4
#define LCD_DB6                PORTB5        // PB5
#define LCD_DB7                PORTD7        // PD7

//    PortB:     7 6 5 4 3 2 1 0
// LCD Data:      2 1 0            Use DB3 to avoid Timer1 pins.
// LCD Data:      2 1     0
//
// PortD:     7 6 5 4 3 2 1 0
// LCD Data: 3

#define LCD_PORTB_MASK            ((1 << LCD_DB4) | (1 << LCD_DB5) | (1 << LCD_DB6)) // Modified to avoid using DB1
#define LCD_PORTD_MASK            (1 << LCD_DB7)
#define LCD_PORTB_DATA(data)    ((data & 0x07) << 3) // Modified the data mask to avoid using DB1
#define LCD_PORTD_DATA(data)    ((data & 0x08) << 4)

The below pictures show the LCD pin layout.
<blockquote”>Red = VCC

Black = GND

BLUE = Voltage for contrast or backlight

Orange = Data lines (4-bit: DB4 – DB7) PB3 (not PB1), PB4, PB5, and PD7. Arduino Digital pins 11 (not 9), 12, 13, and 7

Purple = Control lines (RS, R/W, E) PD2, PB0, and PD4. Arduino Digital pins 2, 8, and 4

So now we have PWM for our retrograde analogue hands, and a LCD display.

But wait, there’s more…

There’s too much display going to waste, so let’s add something else… Hmm… Temperature, and time, make a min/max thermometer that can show what time each extreme temperature was reached during the day.

Quickly getting a LM335Z temperature sensor, I’m now testing whether the 10bit ADC is good enough to generate reasonable temperature readings from the device. At full range of 5000mV across 1024 levels, we have about 4.88mV per level. The LM355Z produces 10mV per degree, so we should be able to get 0.5 degree accuracy. If everything is perfect.

Currently the temperature gauge works, but the accuracy is still a work in progress, as are the min / max functions. The LM335Z has only two connections, and is biased by a single resistor (3200 Ohm), so it will fit into the board if that is all that is needed. Getting perfection may require addition of decoupling capacitors on AREF and across the sensor, but I’m still
experimenting with this.

The overall working product is shown below. But wait, there’s more…

I was not happy with using resistors to tie up the SCL and SDA lines high for the I2C bus, as it should be possible to use the internal pull up resistors in some situations (according to the Atmel datasheet).

So using a new Freetronics 2010 from Little Bird Electronics, the clock is now rebuilt without external pull up resistors. The I2C code is modified to only pull up the lines between the start and stop bus instructions. The levels are messy (not showing sharp transitions in my SLO) but, never the less the code and the clock works.

The working device is shown below. Note the rather funky white on blue display I got from Sparkfun.

In the years since this instruction was writen, I’ve migrated to Github. So the code is hosted here. The freeRTOS code is also posted on Github. I used the Pololu Library for writing to the display, so it needs to be installed along with the normal AVR libraries.

Part 3 will look at how to build a really stylish clock face that can be shown off in public

Freetronics 2010 (Arduino Duemilanova) freeRTOS Real Time Clock (DS1307) – Part 1

Posted on June 17, 2010 by feilipu

I was pondering the blank space on my 2010 recently, and combining that space with some other left over kit from Dogbot, I decided to make a dual retrograde analogue clock.

To build the clock I have the choice of either using NTP to sync a wireless enabled device, or use a RTC clock and re-set it every month or so. For this iteration, I’ve decided to go the RTC route.

Actually, reading this Tronixstuff page also got me going on the idea of using a DS1307 chip, and also Sparkfun makes a nice module that just happens to fit in the vacant space on the 2010. So, I bought one from LittleBird Electronics.

Only other thing to do was to add some servo headers, to get me going with the analogue clock face (using servos).

The picture below shows the layout. I tried a few different options, but this layout seems to only affect the legibility of the pin labelling. Other layouts mask the crystals close together, and I’m not sure how that would affect clock accuracy, or prevent the battery from being removed (9 years later).

Yes, everything fits. Now to the soldering iron.

Ok now it is soldered together, and everything looks reasonably fine.

Now, on the test bed, I have the RTC clock working well using my beloved freeRTOS, and can get on with using the servos to drive analogue hands.

Part 2 looks at building the PWM control for the retrograde hands, and adding a temperature function.

DogBot – Post 5

Posted on May 10, 2010 by feilipu

So some time has passed and I’ve had some success with different aspects of my robot.

For simplicity, I’m using a test bed based on an Arduino Duemilianova connected to a Nerdkits sourced display. I’ve hooked the display up as if it was a Pololu Orangutan SV-328 and am using Pololu libraries to write to it. Also, I’ve been working on the actual SVP based robot, so both of which are working well.

The processor 328p is used for the Duemilianova and requires the use of the Timer0, which implies no Pololu motor library code is possible without conflicts. However this is not an issue, as the Duemilianova doesn’t have motor drives anyway. The actual DogBot has the 1284p which is used in the SVP and uses Timer3, which has no limitations on any known libraries to my knowledge.

The freeRTOS code is posted on the Pololu Forum, mostly just back-up as the application code is very immature.

At this stage I’ve got all of the I2C bus based sensors working, based on code developed by Fleury. So, I can read the thermal sensor for its 8 pixels, and equally importantly, I can read the SRT10 Ultrasonic Sensor for distance in cm. One issue with the ultrasonic sensor is that its field of vision is so great that it basically detects anything “in front” of it. Good to not run into things, but pretty useless as a fine directional capability. It seems lucky that the Sharp IR distance sensors are very directional, and sufficiently accurate as a complement. The analog sensor readings are working well too, though I still have to create a ADC to cm regression.

From the point of view of sensing, it looks like the Sharp IR sensors will be the reference. With the SRT10 sonar being most relevant to create a “zone of safety” where I can be assured that the nearest object in a cone of 120deg is measured, but can’t be sure exactly which direction the object is. On the thermal side, I will get a vector (direction and temperature) from the sensing location, but no distance. But, that I knew and expected.

Putting some effort into designing the motor control, or Transport Task, has taken up my thoughts recently. I don’t want to link the odometry available from the quadrature encoders back into the mapping or routing task. Similarly, I don’t want to link the intertial navigation available from yaw and linear acceleration sensors into the motor task.

I think the transport task should simply take a vector, relative to the the current pose of the robot, and execute these translation commands subject to feedback from odometry, leaving the inertial navigation to another task.

This fits well into the design of the hardware, as odometry can can be queried from the Pololu SVP ancillary processor, without blocking, and the motor PWM drivers can be also managed without blocking other tasks. This creates a self contained task that does not need to share resources with other tasks.

However, the inertial sensors are analogue readings and the ADC will need to be shared with the Sharp IR distances sensors. Creating the need for a semaphore, and blocking based on the availability of the ADC.

Because of the battery issues described in Post 4, I’ve had to remove the servo neck of the DogBot. Therefore, I will implement the option for motion to be along circular paths, as well as along a straight line. Motion along a straight line, with stationary rotations to create the correct pose prior to departure, are the best paths to arrive at the destination with the lowest risk and shortest path. However, with a fixed sensor head, straight lines don’t fill the map with information as they leave the sensors always pointing in the same direction.

If the DogBot proceeds from A to B via a circular route (if this is requested by the mapping or logistics task), then the sensors will be pointed at all directions from +90 to -90 degrees along the path to the destination. Allowing the travel time to be used effectively for data acquisition.

If I’m feeling smart, then I can create any number of route subdivisions, and force DogBot to describe a path of smooth semicircles to the destination, gathering sensor data along the route.

The inertial sensors can be run in a parallel task (using the ADC along with the Sharp IR sensors), with the odometry (from the ancillary processor) to cross check that the expected distances and directions are traveled. Whilst I think the odometry is more likely to be accurate, the map will be updated constantly so some inaccuracy should be expected and tolerated by the code.

My next step is to design this transport task. This task should take distance, bearing and path description (straight line, circle, sinusoidal, etc) and carry it out to the best of its ability (odometry PID data only). I expect resolving this effort will take the next few weeks, and perhaps longer.

Later work is to develop the logistics and routing task that will issue the navigation requests to the transport task.

Continued with Post 6 (one year later).

Dogbot – Post 4 – Hardware & freeRTOS Complete

Posted on April 17, 2010 by feilipu

Ok so some time later, I’ve finished building up the hardware.

It is basically a 4 level stack, with the two Li batteries on the bottom, followed by a proto board which carries the acceleration sensors, and distributes power and signal lines.

The top level is the Pololu SVP and its daughter display card (level 5).

25742_419162736067_610931067_5621385_2222535_n

25742_419162646067_610931067_5621384_4844593_n

25742_419162756067_610931067_5621386_5021337_n

25742_419162776067_610931067_5621388_4697390_n

25742_419162806067_610931067_5621389_6666628_n

25742_419162876067_610931067_5621390_4382446_n

What issues are there?

Well electrically none. All the signals are working perfectly, as demonstrated by the Pololu Analogue and Digital code, together with their motor and servo code. All the hardware seems to be functioning perfectly.

But, there are some problems.

The Li battery packs are incapable of providing enough current. I should have done a power budget before building. Everything works pretty well, although there is some voltage droop to 4.5V, until I turn on the neck servo. Then Vcc drops to 3.5V and the DogBot dies.

So the choices are to remove the servo, and program the scanning function using the body, or build a new boost power supply. At this stage I’m tending to think it would be better to just remove the neck servo, and use the chassis for scanning.

Also finished is the freeRTOS port, using Timer3 from the Atmel MegaAT1284, which is not found on other devices of this type. This allows me to have no conflicts with previously written code (using Timer0, Timer1, or Timer2). However, I will still need to go through all libraries to ensure that they don’t cause problems by being interrupted by the RTOS.

So now onto some heavy system design to work out exactly how to implement the mapping and searching functions, and how to drive in a straight line.

Wifi Dogbot – Post 3 – Pin Outs

Posted on March 12, 2010 by feilipu

Changed the processor to Pololu Orangutan SVP

*** PIN OUTS DEFINED

For the Orangutan SVP from http://www.pololu.com

Port Pin Orangutan (Alternate Functions) Function Notes

PA0 (ADC0) IR Analogue Distance Sensor GP2Y0A02YK0F (20cm-150cm) to ~2.8V – ORANGE
PA1 (ADC1) IR Analogue Distance Sensor GP2Y0A21YK0F (10-80cm) to ~2.8V – WHITE
PA2 (ADC2) LISY GIRO Z Axis Analogue Sensor to 3.3V – PURPLE
PA3 (ADC3) MMA7260QT Three Axis Accelerometer – X Axis Analogue to 3.3V – YELLOW
PA4 (ADC4) MMA7260QT Three Axis Accelerometer – Y Axis Analogue to 3.3V – BROWN
PA5 (ADC5) MMA7260QT Three Axis Accelerometer – Z Axis Analogue to 3.3V – GREEN
PA6 (ADC6) Motor1 Current sense – WHITE
PA7 (ADC7) Motor2 Current sense – WHITE

PB0 (T0) LCD control line RS Timer/Counter 0
PB1 (T1, CLKO) LCD control line R/W
PB2 (AIN0, INT2) LCD control line E
PB3 (AIN1, OC0A) Timer0 PWM output A? PIR (Digital LOW) – YELLOW (& RED & GREY)
PB4 (SPI_SS, OC0B *) Timer0 PWM output B
PB5 (SPI_MOSI) auxiliary processor control
PB6 (SPI_MISO) auxiliary processor control
PB7 (SPI_SCK)? auxiliary processor control

PC0 (I2C_SCL) Ultrasonic Ranger SRF10 Addr 0xE0 & Thermopile Addr 0xD2 – BROWN
PC1 (I2C_SDA) Ultrasonic Ranger SRF10 Addr 0xE0 & Thermopile Addr 0xD2 – ORANGE
PC2 LCD data line DB4 – user pushbutton (pressing pulls low)
PC3 LCD data line DB5 – user pushbutton (pressing pulls low)
PC4 LCD data line DB6 – green user LED (high turns LED on)
PC5 LCD data line DB7 – user pushbutton (pressing pulls low)
PC6 Motor2 direction control line – LEFT MOTOR
PC7 Motor1 direction control line – RIGHT MOTOR

PD0 (USART0_RXD0)
PD1 (USART0_TXD0) digital I/O red user LED (low turns LED on)
PD2 (USART1_RXD1, INT0)
PD3 (USART1_TXD1, INT1)
PD4 (OC1B) Timer1 PWM output B – Buzzer
PD5 (OC1A) Timer1 PWM output A – I/O servo SPWM? – Neck Servo
PD6 (OC2B) Timer2 PWM output B – Motor2 speed control line
PD7 (OC2A) Timer2 PWM output A – Motor1 speed control line

AREF VCC 3.3V Battery Supply

IN PHYSICAL ORDER

TOP RIGHT TO LEFT

PD5 (OC1A) Timer1 PWM output A – I/O servo SPWM – Neck Servo
Quadrature Sensor D – YELLOW (LEFT 2nd)
Quadrature Sensor C – WHITE (LEFT 1st)
Quadrature Sensor B – BLUE (RIGHT 2nd)
Quadrature Sensor A – BROWN (RIGHT 1st)
GND

BOTTOM RIGHT TO LEFT

VIN
GND
M1 OUT B – PURPLE (RIGHT)
M1 OUT A – GREY (RIGHT)
M2 OUT B – ORANGE (LEFT)
M2 OUT A – GREEN (LEFT)=

PD3 (USART1_TXD1, INT1)
PD2 (USART1_RXD1, INT0)
PD1 (USART0_TXD0) digital I/O red user LED (low turns LED on) blank
PD0 (USART0_RXD0) blank – reserved

PC1 (I2C_SDA) Ultrasonic Ranger SRF10 Addr 0xE0 & Thermopile Addr 0xD2 – ORANGE
PC0 (I2C_SCL) Ultrasonic Ranger SRF10 Addr 0xE0 & Thermopile Addr 0xD2 – BROWN
PB4 (SPI_SS, OC0B *) Timer0 PWM output B
PB3 (AIN1, OC0A)???? Timer0 PWM output A PIR (Digital LOW) – YELLOW (& RED & GREY)

PA0 (ADC0) IR Analogue Distance Sensor GP2Y0A02YK0F (20cm-150cm) to ~2.8V – ORANGE
PA1 (ADC1) IR Analogue Distance Sensor GP2Y0A21YK0F (10-80cm) to ~2.8V – WHITE
PA2 (ADC2) LISY GIRO Z Axis Analogue Sensor to 3.3V – PURPLE
PA3 (ADC3) MMA7260QT Three Axis Accelerometer – X Axis Analogue Sensor to 3.3V – YELLOW

PA4 (ADC4) MMA7260QT Three Axis Accelerometer – Y Axis Analogue Sensor to 3.3V – BROWN
PA5 (ADC5) MMA7260QT Three Axis Accelerometer – Z Axis Analogue Sensor to 3.3V – GREEN
PA6 (ADC6) Motor1 Current sense – WHITE – RIGHT MOTOR
PA7 (ADC7) Motor2 Current sense – WHITE – LEFT MOTOR

AREF VCC 3.3V Battery Supply (to centre board) – BLUE

Wifi Dogbot – Post 2

Posted on March 8, 2010 by feilipu

Construction NOTES

1. Build chassis platform for use indoors.

Chassis platfrom elements come from Pololu, so it will be good to use their Orangutan libararies wherever possible. I will need to modify them as the Arduino/Blackwidow runs at 16MHz (not at 20MHz).

Should I modify Arduino/Blackwidow to use 20MHz crystal, to save modifying all the Orangutan, and also to gain 33% more cycles/sec? Or, modify all the code and timing?

Webbot Lib is a library that addresses most issues associated with building robots. Version 1.15b is current now.
http://webbot.org.uk/iPoint/30.page

2. Build motor controls to allow straight line, radius, and Bézier motion.

Basic information on how to get differential drive working.
http://www.societyofrobots.com/programming_differentialdrive.shtml

Then how to add PID control to the system.
http://www.societyofrobots.com/programming_PID.shtml

Some of the Orangutan & Pololu libraries are directly relevant:
OrangutanMotors – basis for control of the DC motors.
PololuQTRSensors – basis for reading the Quadrature sensors from Pololu.
PololuWheelEncoders – basis for reading the Encoders on the Wheels.

CourbeBezier Libraries are interesting for describing Bezier curves.
http://jppanaget.com/doku.php/wiki:bezier_curves

3. Build emergency collision avoidance.

Some of the Orangutan & Pololu libraries are directly relevant:
OrangutanPulseln – basis for reading the short range sensors.
OrangutanDigital – basis for reading the short range sensors.

4. Build long distance sensors.

A very good description of the chosen Sharp optical rangefinders.
http://www.societyofrobots.com/sensors_sharpirrange.shtml

And this is a description of the Sonar Ultrasonic rangefinders.
http://www.societyofrobots.com/sensors_sonar.shtml

Some of the Orangutan libraries are directly relevant:
OrangutanAnalog – basis for reading the Sharp Optical Rangers

5. Build voice box – bark, growl, yap, whine, etc.

This code at Arduino might be useful.
http://www.arduino.cc/en/Tutorial/PlayMelody
http://www.arduino.cc/playground/Code/MusicalAlgoFun

6. Build area mapping.

Using the wavefront technique seems very relevant, from Society of Robots
http://www.societyofrobots.com/programming_wavefront.shtml

7. Build aggressive object collision avoidance.

Some of the Orangutan libraries are directly relevant:
OrangutanSPIMaster – can drive the interfaces with the WIFI device on Blackwidow.
OrangutanSPIMaster – can drive the interfaces on the Ultrasonic Ranger.

Use the 6DOF Atomic Gyros & Acelerometer code as basis

8. Build aggression response.

Some of the Orangutan libraries are directly relevant:
OrangutanSPIMaster – can drive the interfaces on the Acceleration & Yaw sensors.
OrangutanSPIMaster – can drive the interfaces on the Ultrasonic Ranger.

9. Build WiFi sensors & target mapping.

Some of the Orangutan libraries are directly relevant:
OrangutanSPIMaster – can drive the interfaces with the WIFI device on Blackwidow.

A general website for location technique comparisons
http://www.positioningtechniques.eu/lbs_technique_checker.asp

The RTLS from 802.11k is useful, as are the equations for solving based on iso-power intersections of two circles.
http://mathworld.wolfram.com/Circle-CircleIntersection.html
http://local.wasp.uwa.edu.au/~pbourke/geometry/2circle/
There is a C code example to be followed.

10. Build intelligence logic to enable end result.

Webbot Lib is a library that addresses most issues associated with building robots.
http://webbot.org.uk/iPoint/30.page

Use the Seeker2 source where possible, from Society of Robots.
Research into finite state machines required.

Also there is an Experimental Robot Platform code that is being provided ERP_WebbotLib
that will be very relevant.
http://www.societyofrobots.com/robot_ERP.shtml

11. Build Thermal sensors & target tracking.

Some of the Orangutan & Pololu libraries are directly relevant:
OrangutanServos – can drive the PCM interfaces to the pan servo for Thermopile Sensor (option).

WiFi Dogbot

Posted on March 8, 2010 by feilipu

I was looking for a “why” for investing my time in Atmel AVR devices, because with a “why” progress is always faster. I think making an autonomous robot with dog-like behaviour will make an excellent one / two year multi-layer project, that will be able to demonstrate itself at the end. Also it won’t consume too much cash.

This post is to create a problem description, expected outcomes, and path I’ll be taking. It will also be a reference when I forget where I was going with this.

Why?

Being able to find my ‘Droid when it has gone missing around the house, and (more reguarly) being able to find my wife’s Crackberry is a fairly regular occurrence. So, I’d like to build something that can find both of these WiFi enabled devices. Also, being able to search out iPhones and WiFi APs, like a drug sniffer dog, would be mildly entertaining for family and visitors.

Expected features

Autonomously seek out and approach WiFi sources in order of strength.
“Bark” when the device is in close proximity.
Navigate & travel at dog speed in an unfamiliar environment.
Avoid aggressive obstacles within the map. “Growl” at these obstacles.
Reorientate autonomously if an aggressive obstacle “picks up” or “plays”.

Optional features

Follow someone around whether or not they have a WiFi device.

Assumptions

The floor is flat. Litter can be avoided. -> a cheaper indoor chassis can be used.
The room is small. 10m x 10m map can be built, with translation as map edge approached. -> memory conservation.

Initial Plan

Build chassis platform for use indoors.
Build motor controls to allow straight line, radius, and B?zier motion.
Build emergency collision avoidance.
Build long distance sensors.
Build voice box – bark, growl, yap, whine, etc.
Build area mapping.
Build aggressive object collision avoidance.
Build aggression response.
Build WiFi sensors & target mapping.
Build intelligence logic to enable end result.
Build Thermal sensors & target tracking.

Component sourcing

Chassis

1x Pololu 5″ inch Robot Chassis RRC04A http://www.robotgear.com.au/Product.aspx/Details/353
1x Pololu 42 x 19mm Wheel and Encoder Set http://www.robotgear.com.au/Product.aspx/Details/307
1x TB6612FNG Dual Motor Driver Carrier http://www.robotgear.com.au/Product.aspx/Details/319
1x Pololu Ball Caster with 1″ Plastic Ball http://www.robotgear.com.au/Product.aspx/Details/370
2x 30:1 Micro Metal Gearmotor http://www.robotgear.com.au/Product.aspx/Details/344

1x Arduino Duemilanove http://arduino.cc/en/Main/ArduinoBoardDuemilanove
(will be replaced in step 9.)
1x Arduino Proto Shield http://www.sparkfun.com/commerce/product_info.php?products_id=7914

Emergency Sensors

3x Pololu Carrier with Sharp GP2Y0D810Z0F Digital Distance Sensor 10cm
http://www.robotgear.com.au/Product.aspx/Details/309

Long Distance Sensors.

2x Sharp GP2Y0A02YK0F Analog Distance Sensor 20-150cm http://www.robotgear.com.au/Product.aspx/Details/272
1x SRF10 Dual Transducer Ultrasonic Ranger http://www.robot-electronics.co.uk/htm/srf10tech.htm

Voice Box.

1x Piezo Buzzer from NerdKits

Aggression Sensors.

1x MMA7260QT 3-Axis Accelerometer http://www.pololu.com/catalog/product/766
1x LISY300AL Single-Axis Gyro http://www.pololu.com/catalog/product/765

WiFi Sensor (and revised Microcontroller Platform).

1x BlackWidow 1.0 http://www.seeedstudio.com/depot/blackwidow-10-p-613.html

Thermal Sensor.

1x Thermopile Array http://www.robotgear.com.au/Product.aspx/Details/294

So, maybe the next post once some more details are to hand.

	Equipment Rack for W… on Sleeping Arrangements
	Equipment Rack for W… on James Baroud Evasion RTT on a…
	Equipment Rack for W… on Stockman Pod Extreme Delivery…
	Equipment Rack for W… on Wrangler JL Rubicon – Bu…
	Equipment Rack for W… on Curb Weight

Gone Bush

Stuff I need to write down.

Tag Archives: Pololu