Your thoughts on a project idea please?

[Mike_cj0]

Hello!

I have a big(ish) project i would like to have a go at building. My idea is to convert my RC car into an autonomous vehicle that can be given a set of gps co-ords and set on its way to get there by itself.

I realise this is possibly a hugely complicated senario. So first off i have a couple of assumptions. The area to use it will have nothing to squash the car (full sized cars etc) and no moving obstructions. Also no stairs etc and it wont have to follow roads. I can always try to add functionallity to copy in the dark and distant future.

I think the best approach would be to do this is a step by step process.
1. get car driving in a predefined pattern at varying speeds
2. add gps and maybe a compass and get it to drive in a straight line to target
3. add ultrsonics to detect obsticals and avoid them

So does this seem like a sensible approach?

Would a gps module alone be sufficient or would having a compass as well be a good idea?

I have seen a few different approaches to using ultrasonics. Single fixed unit on front. single unit mounted on servo and 'scanned' from side to side or multiple units positioned to give a wider field of view. What approach would be best?

Thanks for your time,
Mike

 

[srnet]

This might be a good place to start, read this thread, the distances are much greater, but the techniques for using a PICAXE & GPS to get to a set point would be the same.

http://www.picaxeforum.co.uk/showthread.php?18952-PICAXE-handling-GPS-for-robot-boat

The calculation of a straight line to a target set of GPS co-ordinates is going to difficult with PICAXE basic, you really need floating point maths, although there is the option of a floating point co-processor.

However in practice would you need a straight line at all ? As long as the general direction is OK, and the distance is getting smaller (which you can tell from the GPS reported co-ordinates directly) that should be enough. Especially if you assume that object ovidance is inevitable.

 

[erco]

Google RoboMagellan for plenty of info.

http://robogames.net/rules/magellan.php

 

[hippy]

It's all quite simple in principle - You know where you are, know where you want to be, so determine a heading to get there. If you know which direction you are facing, you know by how much to turn and in which direction. Or you can work out your direction from where you were and where you are now. If something gets in the way, go round it, and things will sort themselves out when you next look at where you are and where you want to be.

I imagine most problems come about through accuracy in some form or other and it's probably hard to tell what makes something so seemingly simple so difficult in practice without trying it and experiencing it. If it were easy there would likely be few failures when attempting to achieve it and that seems counter to reality.

It's a feasible project but also likely to be an involved one, full of trial and error, but there are shoulders to stand on.

 

[bluejets]

I believe there is a competition each year in the US that pays big money if you can complete a certain route.
I think it is more involved than first meets the eye as there has been limited success. Just be prepared for a long haul.

 

[Mike_cj0]

Thanks for all the responses.

It looks like its a possible project and as long as i take little steps it shouldnt be to complicated, at least to start with!

I have seen before about the Darpa challenge. I think that is way beyond what i could ever consider doing! Now RoboMagellan looks interesting!

Thanks for the link to the robot boat project. I had found an early thread about it which was quite interesting. That one is even better.

I have been through all my electronics bits over the weekend and dug out a couple of 08 and a 28 pin picaxe.

First job will be to hook up a couple of servos to the 08 and have a play making them do stuff. Then i will hook it up to my car and try and get it to do a figure of 8 in the carpark.

Having read some other threads on similar projects it looks like the frequency the picaxe runs at can cause complications with the use of the servo command and serial inputs depending on baud rate (if i have understood thigs right).

My thinking was to use an 08 as a I2C slave to control the servos in the final project. Another picaxe to read in the GPS data and act as an I2C slave as well. My thinking would be that this should get round some of the problems with controling the servos.

 

[SAborn]

The 08 might not be the best choice for a I2C slave as it dont have I2C in the firmware, the 08m2 do have I2C in the firmware and would be a much better choice for the slave chip.

 

[Mike_cj0]

Thats a shame about the lack of i2c support. I had hoped to save a few pounds re-using old parts.

How can i identify which version 28 leg picaxe i have? I would have bought it in 2008 or there abouts.

 

[sedeap]

Thats a shame about the lack of i2c support. I had hoped to save a few pounds re-using old parts.

How can i identify which version 28 leg picaxe i have? I would have bought it in 2008 or there abouts.

Look into manual 1 Page 16 (Px Chip Labels)

http://www.picaxe.com/docs/picaxe_manual1.pdf

C U pal...

)

 

[Mike_cj0]

Thanks for pointing out that page. Those manuals are a wealth of information. Almost a bit to much to find everything!

I will have to wait impatiently till i get home from work to check!

I think to do this project i am going to have to buy some new chips.


My current thinking is -

08M2 for I2C slave servo controller
uM-FPU for GPS
????? for ultra sonics (either one to three SRF008 or a picaxe of some kind to read in and control one to three SRF005)
????? for master control of I2C slaves and for running main program

Any thoughts or suggestions?

Cheers
Mike

 

[hippy]

Not sure what the servo control is for but I'd suggest rather than having a scanning ultrasound sensor ( if that's the idea ) have multiple fixed sensors, otherwise sod's law will have it pointing in some other direction than what you are about to crash into. If considering a servo for steering I'd personally go for standard 'motor each side' drive.

The idea of slave PICAXE to control or handle things is a good idea, but the simpler you can make things usually the better.

 

[Mike_cj0]

Sorry, my description of servos isnt very accurate.

What i was planning on controlling with that slave would be the steering servo and speed controller for the car.

The car im using is a yokomo 4wd drift car that has been modified to lift the suspension and has kobbly off road tyres fitted instead of the drift tyres.

I would agree that having a rotating sonar would be a bad idea. Would be ok if the car was very slow but anything over a crawl would almost certainly fall into the realms of the law of sod.

 

[eclectic]

Thats a shame about the lack of i2c support. I had hoped to save a few pounds re-using old parts.

How can i identify which version 28 leg picaxe i have? I would have bought it in 2008 or there abouts.

Two other useful sources are

1. The P.E. Firmware check, for the chip model and version.

2. firmware.txt
In Windows, it's found in
C: > Program Files > Programming Editor.

e

 

[geoff07]

My current thinking is -

08M2 for I2C slave servo controller
uM-FPU for GPS

Think at least twice before you commit to the FPU. Write some trial code to see how easy (not) it is. Unless you can borrow some working code you may find it takes all the fun out of the project, as you are effectively programming a different animal with a low-level interface, a steep learning curve and a less-friendly development environment. On the other hand, if you are successful, I suspect many will want your code! Me for one.

 

[papaof2]

Think at least twice before you commit to the FPU. Write some trial code to see how easy (not) it is.

I've seen code for the FPU that reads a GPS, does the math, and tells you which direction (right, left) and how far (7 degrees) to turn. That code runs about 15-20 printed pages. I'm under an NDA, so I can't share it :-( If you've seen any assembly language listings, it would look familiar...

Fot a first attempt at an autonomous vehicle, you should look at Robin's code for steering a sea-going model sailing ship http://www.picaxeforum.co.uk/showthread.php?18952-PICAXE-handling-GPS-for-robot-boat If that code doesn't have all the "bells and whistles" that you want, it would be MUCH easier to modify working PICAXE code than to create your own from scratch (on any platform).


John

 

[westaust55]

Using a uM-FPU chips is certainly possible but can take some time to get yourself up to speed.
I have done some work with the uM-FPU V2 chip. Note that the uM-FPU V3.1 includes GPS parsing instructions.

Be aware that if you write the program entirely within the PICAXE to send instructions and data to the FPU, that, from my experience with the uM-FPU V2 chip, it may occupy more PICAXE program space and time than performing the calculations within the PICAXE. You will need to consider developing function blocks and permanently storing these within the FPU so the PICAXE need only send data, initiate a calculation and then read back the result.

For a GPS related project. you may glean some of the required program theory from the PIC source code listing here: http://www.photopete.com/swarm/gpsTruck.htm

 

[Mike_cj0]

Thanks for the heads up on the complexity of using the FPU. I had hoped it would make life simpler.

I have found this application note for the fpu v3.1 http://micromegacorp.com/appnotes.html - Application Note 36 - Reading GPS Data

It has some example code that doesnt look to horrendous but if a similar result can be done in a picaxe with less hassle then the picaxe is probably the way to go. Especially considering the fpu v3 is more than double the price of a 40x2

 

[hippy]

Thanks for the heads up on the complexity of using the FPU. I had hoped it would make life simpler.

I'd have thought so too but I haven't done it and that's when you find how complex or straight forward it is.

There's often little choice but to try it and see. It may be that the code is fundamentally simple but then there are special cases, error cases and other things which need to be handled to build a rock solid solution. Usually those things won't need to be added but can come later when you've also got experience under your belt which makes it far easier to add those.

 

[Mike_cj0]

So the next question is then...

If i dont use the FPU, which picaxe would be most suitable to decode the data from the gps? Looking at the datasheet for the LS-41EB all i should need is the values from the $GPRMC during normal running and $GPGGA at start up to make sure i have a good fix.

 

[westaust55]

@Mike_cj0,

To elaborate on my earlier post:
While using the uM-FPU chips can be complex, if you do add code function blocks programmed within the FPU chip (as opposed to sending the necessary instructions every time with the data) it will take time to develop the software but can save PICAXE program space and time to achieve the end result of a calculation.
The end result should also be less chance of math overflow issues and greater accuracy with the math end result.

Having done some relatively complex math (relative to the PICAXE chips used) for temperature and humidity calculations in an 18X the program became complex in that case due to limited variables and need to deal with larger numbers without overflow. Later PICAXE chips have more variables but the need to retain math accuracy and prevent overflow in reults still exists.
I my case I used a uM-FPU V2 but did not see PICAXE program size improvement or speed improvement until I started using the FPU internal function block capability.

Others on this forum have in the past done some work parsing GPS data streams directly with a PICAXE chip so no doubt a forum search my help get you started with undertanking the initial work of getting the GPS data into a PICAXE. How much further those projects have gone I cannot say.

So my thought is that it could be as much work/effort to generate a solution for you project by (a) All code within a PICAXE versus (b) adding a uM-FPU V3.1 chip.
The potential advantage of the FPU chip is once the project is operational there would be a reduction in work to be performed by the PICAXE chip in parsing GPS data and having the results available faster if you take the time to develop function blocks to be stored within the FPU chip.

 

[hippy]

If i dont use the FPU, which picaxe would be most suitable to decode the data from the gps?

It's more the maths having decoded the data which will be the challenge without a uM-FPU and, as it's such an open-ended question without some initial attempts to do it, I'd suggest heading straight to top of range; 28X2 or perhaps 20X2 if you want 64MHz but no external crystal.

Either way it seems you'll have some work to do, interfacing with uM-FPU or implementing the maths, and I've no experience of either. My approach would be an R&D prototyping sub-project, taking two coordinates defined in the program and determining the bearing between them. That could be implemented for a PICAXE without hardware using simulation.

It's the age old problem that if no one has already done it, the answer isn't there, you have to try it and find out yourself.

 

[Mike_cj0]

Now thats a good idea. Will give me a fair idea of how complicated it will be.

I have done a fair bit of gps decoding in VB in the past so i know what calculations are required. This application should be simpler than my VB one as that needed to take into account altitude as well as lat and long when working out distances. On the scale i will be use the picaxe for i think it will be safe to assume a flat plain at sea level. If that works out ok i may add in altitude calculations at a later point. we shall see.

 

[westaust55]

Further to my comments at post 20, thinking further . . .

My previous comparisons are based upon a PICAXE at 4 MHz and a uM-FPU V2.

According to the literature, the uM-FPU V3.1 performs math functions 10 to 20 times faster than uM-FPU V2 for all floating point operations.

As such you should see a speed improvement if using the uM-FPU V3.1 relative to using a PICAXE chip at slower speeds.

 

[hippy]

This may be of interest ...

http://micromegacorp.com/downloads/documentation/AN036-GPS.pdf

Though the code is a bit long-winded It's simply taking a GPS string, finding the right fields, converting to numbers. Should be easy enough to then take those numbers and destination coordinates and calculate some more to get a heading to follow.

Once programmed, GPS connected to it and target coordinates provided it seems the uM-FPU v3 could be used as a standalone peripheral simply delivering heading when asked for it.

That seems the easiest option to me. You'll have to develop the uM-FPU 'assembly code' but there won't be much to do on the PICAXE side of things beyond setting the target and reading the heading.

 

[Mike_cj0]

I have been having a play with doing the maths on a simulated 28x2

It's not proving simple!

The method for working out the distance between two sets of co-ord is to first convert long and lat values into degrees.
Then convert degrees to radians.
assuming northern hemisphere and west of greenwich meridian and constant altitude on perfect sphere
X distance = 6367 * cos(- longitude) * sin(90 - Latitude)
Y Distance = 6367 * sin(- Longitude) * sin(90 - latitude)

Straight Line Distance from point A to point B = square root of ((X * X) + (Y * Y))

surface distance = 2 * 6367 * sin^-1 (straight line distance / 2 * 6367)

I managed to get some basic figures out but even using various tricks to cope with decimal points the final accuarcy was a long way out. No where near good enough.

Im still very new at any picaxe programming let alone doing this level of maths so there is a good chance i have missed some clever little tricks to improve accuracy but it's not looking good for using the picaxe to do the calculations

 

[hippy]

Limiting yourself to native 16-bit unsigned maths may be unlikely to deliver.

There are potentially two things which can help; finding algorithms which are more integer friendly and/or non-trigonometric plus coding up some routines which allow larger and signed integer, floating point and trigonometric maths to be more easily handled. The later approaches implementing what the uM-FPU does for you on a PICAXE.

It's unlikely to be a ten minute job and will require thinking about what's needed and how to do it, along with perhaps learning new skills and techniques. Floating point libraries aren't impossible but you have to understand floating point theory to implement them. Likewise you may have to implement trigonometric functions from first principles.

You have to weigh-up time and effort in doing it DIY or spending money and buying a uM-FPU; it all depends which you have more or less of.

 

[Mike_cj0]

Thanks for all of the help and advice so far.

I have been having a bit more of a play with the calculations using the simulator.
I have managed to take a series of long/lat co-ords in GPS NMEA format into radians with 4 dp of precision.
I still have a way to go but i am making some progress on a picaxe based solution.

Here is my code so far. Its probably full of flaws and breaks all sorts of rules! Any coding issues you spot im happy to take advice on!

'DDD MM.MMM
' 50 degrees 81.5534 minutes
let w0 = 50 'degrees
let w1 = 81 'minutes
let w2 = 5534 'decimal fraction of minutes

let w3 = 1 
let w4 = 20 
let w5 = 7101

let w6 = 50 
let w7 = 81 
let w8 = 7634

let w9 = 0 
let w10 = 92
let w11 = 0171

'distance between points = 13.1km



'***********************************
'degrees decimal minutes (D m) -> decimal degrees (d)
'd = D+m/60 = 51.3592
'm = 81.5534
'm/60 = 1.3592

'81/60 = 1.35
'0.5534/60 = 0.0092
'1.35 + 0.0059 = 1.3592

'8100/60 = 135
'5534/60 = 92

'135 * 100 + 92 = 13592
'13592/10000 = 1
'13592//10000 = 3592
'50 + 1 = 51

let w1 = w1 * 100 / 60 * 100
let w2 = w2 / 60
let w1 = w1 + w2
let w0 = w1 / 10000 + w0	'w0 = 51
let w2 = w1 // 100		'w2 = 92
let w1 = w1 // 10000 / 100	'w1 = 35
'51.3592
 
let w4 = w4 * 100 / 60 * 100
let w5 = w5 / 60
let w4 = w4 + w5
let w3 = w4 /  10000 + w3	'w3 = 1
let w5 = w4 //100			'w5 = 18
let w4 = w4 // 10000 / 100	'w4 = 34
'1.3418

let w7 = w7 * 100 / 60 * 100
let w8 = w8 / 60
let w7 = w7 + w8
let w6 = w7 / 10000 + w6	'w6 = 51
let w8 = w7 // 100		'w8 = 27
let w7 = w7 // 10000 / 100	'w7 = 36
'51.3627

let w10 = w10 * 100 / 60 * 100
let w11 = w11 / 60
let w10 = w10 + w11
let w9 = w10 / 10000 + w9	'w9 = 1
let w11 = w10 // 100		'w11 = 2 *** remember preceding zero (02) ***
let w10 = w10 // 10000 /100	'w10 = 53
'1.5302

'***********************************
'decimal degrees to radians example
'r = d * pi / 180
'r = 51.3592 * pi / 180
'r = 51.3592 *  0.0175
'r = 0.8988

'51 * 0.0175 = 0.8925
'0.35 * 0.0175 = 0.0061
'0.0092 * 0.0175 = 0.0001
'= 0.8988


'51 * 175 = 8925
'35 * 175 = 6125 / 100 = 61
'92 * 175 = 16100 / 10000 = 1
'=8987

let w0 = w0 * 175
let w1 = w1 * 175 / 100
let w2 = w2 * 175 / 10000
let w0 = w0 + w1 + w2	'w0 = 8987
'0.8987

let w3 = w3 * 175
let w4 = w4 * 175 / 100
let w5 = w5 * 175 / 10000
let w1 = w3 + w4 + w5	'w1 = 234
'0.0234

let w6 = w6 * 175
let w7 = w7 * 175 / 100
let w8 = w8 * 175 / 10000
let w2 = w6 + w7 + w8	'w1 = 8988
'0.8988

let w9 = w9 * 175
let w10 = w10 * 175 / 100
let w11 = w11 * 175 / 10000
let w3 = w9 + w10 + w11	'w1 = 267
'0.0267

'***********************************

 

[Mike_cj0]

I think i have made a school boy error!

Just reading the manual again about the use of sin, cos and atan and realise they use degrees not radians.

This means the degrees to radians conversion i created isnt needed after all

At least it might be useful for someone else.

 

[Mike_cj0]

After nearly three solid days of trying to get this to work i have made the decision to buy the FPU.

I have found various ways of doing parts of the calculations and maintaining acuracy but there is one part that is vital to calculating that just doesnt seem posible to do and maintain accuracy. I think it might work ok if you didnt mind being 5 to 10km out but im wanting to be accurate down to 5 to 10 m

I think what i am going to do i buy the FPU, a 28x2 and a 08M2.

I will use the 08M2 to simulate a gps by outputting a series of nmea strings in a contant loop via the serial out leg.

I will connect this to the FPU's serial in and then the FPU to the 28x2 via I2C.

Doing it this way should allow me to get some code running without needing to be near a window or outside or having to worry about trying to maintain a GPS signal.

Hopefully once i have some code running i can then go an buy a gps unit to interface with it.

I can then use the 08M2 to control the steering servo and the motor speed controller.

Time to go and shop!

 

[Mike_cj0]

My FPU, 08M2 and 28X2 arrived today so i shall start playing this evening.

 

[srnet]

I think it might work ok if you didnt mind being 5 to 10km out but im wanting to be accurate down to 5 to 10 m

Using 32bit floating point maths under Mikrobasic (on a 18F26K22) I get an calculation accuracy of 1 or 2M between two sets of lat and longs that are 1kM apart.

You may have to tweak the calculation by doing some comparisions between what the GPS calculation gives you, and the actual distance on a map.

 

[BESQUEUT]

Are you going to drive your car on an airport taxi-way ?
If not, a 10m error can be enought to go out of the way...
That's why GPS is enought to drive a plane, (and somes did that...) not a car.

For a car, you have to deal with distances and bearing and/or gyroscop.
Good luck for your difficult project...

 

[geoff07]

Just in case it might be of interest, this program by James Miller: http://www.amsat.org/amsat/articles/g3ruh/111.html , written in Basic but using floating point, calculates all the kepler equations for celestial mechanics, in order to track satellites. I have tried but not so far succeeded to convert a version to Picaxe, but I ran out of patience with the FPU and shelved the project. You may find the algorithms useful if you can do some FP emulation perhaps, even if only as orientation for vector maths.

15 years ago I had a 16MHz 386 with 16MB of ram that ran an email client, calculated the position of the relevant microsat, pointed the rotator at the satellite as it came over the horizon and tracked it in real time, calculated the doppler shift and tuned the radio to match, and received the data decoded into the email program. Largely with TSRs. The sats were in polar orbits and I remember chatting with the British Antarctic Survey guys. Granted there is a difference between that and a 40X2 but the gap is getting smaller rapidly. If I can crack the FP problem I want to rebuild this system with a Picaxe.