Gyroscope, theoretical discussion

edmunds

Senior Member
Dear all,

I would not have brought it up, but I could find zero threads on this forum about accelerometers and gyroscopes. As mentioned before, I'm going to try to use one and while Internet is full of Arduino based gyroscope and accelerometer applications, I think it is worth discussing this for our beloved Picaxe as well.

What I want to do is to equip this vehicle with a gyroscope. Then, I want to travel the line as in the video and register angle change (say, yaw axis) the car is at for every 1 mm of travel. Then, I want to reconstruct the angle into a 'virtual line' and feed this back to the steering co-processor instead of the white line information from the sensor and make the car follow the line without there being a line.

I'm thinking about the following roadmap:

1. Get the car to count travelled millimetres, interrupt on it; DONE
2. Get the gyro/accelerometer combo running; DONE
3. Add memory - I2C or SPI min 16kb (something from the parts drawer);
4. Learn to store angle data or pre-calculated virtual line in memory while driving the line;
5. Learn to read the data and feed it back to the steering co-processor (HSERIN?);
6. See if this works.

Am I missing something major? As in, 'this is totally not gone work, you need to go back to school again if you think it could' :).
Any comments on using accelerometer data as well for this? People seem to use gyro and accelerometer combos for indoor navigation and I have one, but I don't quite understand what I could use it for in case I have my odometer (point 1 above). From simple geometry, I should be able to virtually 'segment' the line into 1 mm straights and if chained and angled correctly, I should be able to arrive where I want.


Thank you for your thoughts,

Edmunds
 
Last edited:

BESQUEUT

Senior Member
Am I missing something major?
Picaxe is not able to use trigonometric functions. You'll need a coprocessor. But this may be bypassed.

Gyroscope is not the same thing as gyrometer. I think that you are talking about MEMs gyrometer.
Main difference is that a Gyroscope give you an absolute direction, whereas a gyrometer give you degrees per second.
So you have to cumulate theses measurements ... and corresponding errors.
Accelerometer is no use for this application as travelled millimeters is many more accurate than using acceleration measurements.

Does this mean something for you :
X=1/2 Acceleration * t^2


5. Learn to read the data and feed it back to the steering co-processor (HSERIN?);
That's not enought as what you ask to do will not be what is actually done.
You'll have to measure actual movements, then compare with stored data and adjust...

Gyrometer resolution is something like 0.1 ° per second
So, 1mn may be 6°
10 mn ==> 60°

Maybe you can use a chip whith an integrated mpu (like MPU 6050), but then, you'll have to program the MPU...

IHMO, what you want to do is very, very, very, very difficult with a Picaxe...
 
Last edited:

stan74

Senior Member
I've got similar still in packet. Sort it out and I'll use the code. I only got it because it was cheap.Maybe a digital compass would have been a better choice..for me.
Yes, a line following-object avoiding robot with navigation and play wav files like who put that there? or bollards,I'm lost.
 

edmunds

Senior Member
Picaxe is not able to use trigonometric functions. You'll need a coprocessor. But this may be bypassed.
Of course, I understand that, but different values are not so many, so I was thinking a lookup table again ...

Gyroscope is not the same thing as gyrometer. I think that you are talking about MEMs gyrometer.
Main difference is that a Gyroscope give you an absolute direction, whereas a gyrometer give you degrees per second.
So you have to cumulate theses measurements ... and corresponding errors.
Sorry, if I was not perfect with terminology, but I did mean gyroscope and I understand what I'm getting is d/s. Since the distance is also incremental - 0.9mm per step, this should fit right in. With some geometry I have not fully figured out, of course, at this point.

Does this mean something for you :
X=1/2 Acceleration * t^2
Position from acceleration and time?

That's not enought as what you ask to do will not be what is actually done.
You'll have to measure actual movements, then compare with stored data and adjust...
I understand, but this is how some robots work. I don't remember all the fancy scientific names for it, but you just feed the output back to input kind of on top of a PID algorithm and it produces reasonable results. Yes, the example I saw explained was on Arduino, but then again - I'm travelling quite slowly. So let's see if there is a way.

I actually have MPU6050s here, too, but I did not manage to fire one up and at some point switched my attention to LSM6DS3 because of 10x lower power consumption. But I can certainly revert to it, if I get stuck in math :).

For starters, I have a "hello world!" from LSM6DS3. LGA14 was a bit of challenge to hand-solder wires to after my plan with LGA16 breakout board failed.


Thank you for your input,

Edmunds
 

hippy

Technical Support
Staff member
Much as the PICAXE is great for the tasks it is intended to cater for and more beyond; it's possibly one of the worst choice for tasks which have very specific requirements and are difficult and complex with even a powerful and well specced general purpose computer.

It's not that fast, doesn't support trig, doesn't support floating point, doesn't even support signed integers, can't easily handle anything over 16 bits, has limited program memory, limited variable memory, it isn't deterministic and can't easily support regularly paced timed events or scheduled tasks without considerable and unknown amounts of jitter.

That's not putting the PICAXE down; it's just that all those things are likely to be required for any autonomous navigating system. Many other micros would struggle just as much.

Hoping to do it on a sub-miniature platform, possibly with a PICAXE which is doing a whole lot of other things, is, shall we say "ambitious".

I would consider other more practical tricks; invisible IR lines or just invisible IR markers which can tell the bot by how much to turn and how quickly. I noticed that a lot of the line racing tracks have such markers, usually visible,and I am sure they use those to help make it feasible.
 

edmunds

Senior Member
You'll have to integrate...
Can you explain, why integration would be such a problem in discrete time? PID integration was a piece of cake, because if you do it in discrete time, rather than continuous time, it becomes simple accumulation. Isn't that the whole idea of integration on simple micros?


Edmunds
 

stan74

Senior Member
All true hippy. It's easy to sense a hidden wire but I think the visible line is "expected",not invisible ir lines...it's a set format too often re-iterated but it's so nice to see a simple robot using simple code follow a line although the novelty wears off quickly. No one seems to bother with making an avoidance robot do much else..it fits in "obstacle avoiding robot category". I made an avoiding robot that searched for light,quite interesting. Maybe an avoiding robot that searches a tv remote. Edmunds robot could go ALL around his track and crossing lines would be easier than using 2 sensors and following an edge. How about a few cars on the track? 2 us robots is interesting, I tried it,very amusing if you're easily pleased.
 

edmunds

Senior Member
I've got similar still in packet. Sort it out and I'll use the code. I only got it because it was cheap.Maybe a digital compass would have been a better choice..for me.
Yes, a line following-object avoiding robot with navigation and play wav files like who put that there? or bollards,I'm lost.
Here you are:

Code:
#picaxe 40x2
#no_data
#no_table

;setfreq em64

'Outputs
Symbol SCL = C.3
Symbol SDA = C.4

'Inputs
Symbol INT1 = pinB.1
Symbol INT2 = pinB.2

'Bit and Flag variables
Symbol EV_BOOT = bit27       'Unknown, part of b3 when read from IMU
Symbol TDA = bit26           'New Temperature data available, part of b3 when read from IMU
Symbol GDA = bit25           'New Gyroscope data available, part of b3 when read from IMU
Symbol XLDA = bit24          'New Accelerometer data available, part of b3 when read from IMU


'Constants
Symbol IMUAddress = %11010110
Symbol EEPROMAddress = %10100000

'IMU registers
Symbol CTRL1_XL = $10
Symbol CTRL2_G = $11
Symbol CTRL9_XL = $18
Symbol CTRL10_C = $19

Symbol WHO_AM_I = $0F
Symbol STATUS = $1E

Symbol INT1_CTRL = $0D
Symbol INT2_CTRL = $0E

Symbol OUTZ_L_G = $26
Symbol OUTZ_H_G = $27


init:
  pause 30 'wait 30ms for IMU to boot

  hi2csetup i2cmaster, IMUAddress, i2cfast, i2cbyte
  hi2cout CTRL10_C,($38)
  hi2cout CTRL2_G,($60)
  hi2cin WHO_AM_I,(b4)                                    'Check if IMU is responding
  sertxd (#b4,LF,CR)                                  'Display answer, 105(69h) expected
  
do
  pause 500
  hi2cin STATUS,(b3)
  sertxd (#b3,LF,CR)
  if GDA = 1 then
    hi2cin OUTZ_L_G,(b55)
    hi2cin OUTZ_H_G,(b54)
    sertxd (#w27,"; ")
  endif
loop
The only hick-up was I was not careful enough to read you have to tie SDx and SCx lines high or low if not used (pull-ups if used). Nothing works if left floating.

Good luck,

Edmunds
 
Last edited:

BESQUEUT

Senior Member
Sorry, if I was not perfect with terminology, but I did mean gyroscope and I understand what I'm getting is d/s. Since the distance is also incremental - 0.9mm per step, this should fit right in. With some geometry I have not fully figured out, of course, at this point.
Not only terminology, (since all MEMs are named Gyroscope, even if IHMO they are not...) this is conceptual :
- as with your mm tracking a gyroscope is (for hours) absolute : you can read an absolute heading,
- same for a magnetometer,
- with a gyrometer, heading will vary along time, even if the robot is still !
So time is not your friend ; error will grow with time.

Position from acceleration and time?
YES. So you have the theory...
This can also be used to estimate error versus time... and it is exponential !
So you can understand why (past first second) your mm tracking will be many more accurate than accelerometer and why you can forget it...
 

edmunds

Senior Member
YES. So you have the theory...
This can also be used to estimate error versus time... and it is exponential !
So you can understand why (past first second) your mm tracking will be many more accurate than accelerometer and why you can forget it...
Yes, I got that, thank you for the pointer.

Edmunds
 

BESQUEUT

Senior Member
Can you explain, why integration would be such a problem in discrete time? PID integration was a piece of cake, because if you do it in discrete time, rather than continuous time, it becomes simple accumulation. Isn't that the whole idea of integration on simple micros?
Encoder counting does not involve time : you only have to not miss any pulse.
degrees/s involve time.
If the timing is not accurate (and it's very difficult to have an accurate timing with a Picaxe) the rotation measurement will not be accurate.
Even more if the Picaxe is doing few things at the same time...

Example :
you measure 100°/s during 0.1 s ==> so rotation is from the Picaxe 10° (OK for that ?)
But actually, time is 0.15s ==> rotation is actually 15°

Do that every 0.1s ; what is the error after 10 s ?
 
Last edited:

edmunds

Senior Member
Hoping to do it on a sub-miniature platform, possibly with a PICAXE which is doing a whole lot of other things, is, shall we say "ambitious".
Dear @hippy,

Thank you for your very thorough, albeit less optimistic than I'm used to response :). Ambitios works for me and I have time to spare. 80 to 120 hours to get this working with picaxe.

I'm coming back to this from plenty of research and tests with 'invisible' lines and transparent films. None quite give what I need and have their own problems. For an example, did you know, that while 'invisible' IR reflective inks exist, they fade over time? As in over a month or half a year if you are lucky.

I'm also coming back to this from setting up a tool chain for and getting a 'hello world' thingy from STM32 Cortex M0 processor, because of all the concerns in your response. I did (admittedly, buried under the complexity of STM development tools and platform) understand at one point, I have never pushed the limits and not even clearly and specifically defined what would be required and would not be enough and there was no workaround for with picaxe. I can always revert back to it, but not before I'm convinced there is no way to do it with picaxe. Just out of 'doing the impossible' challenge. And everything I learn will be useful in that more powerful application as well.


Edmunds
 
Last edited:

edmunds

Senior Member
Dear all,

Probably, it is useful to explain, the autonomy does not have to be long lived. As in, if you imagine a model railroad layout, there could be absolute reference points out there quite frequently. Every crossing is, sure a reference point and can have a stop line, an infrared 'ID station' and other markers. Some pot hole covers can be semi transparent and have infrared emitters underneath. Magnets can be hidden under the roadway and cars can be equipped with hall sensors to check their relative position against absolute to the tenth of a millimetre. And finally the 128 pixel array can see some features precisely enough for them to serve as an absolute reference.

So, I do not need miles and miles of full autonomy. If error of 0.1 degree is a standard expected heading deviation with inertial navigation systems in one hour, then the heading error for 30 seconds and max 5m travelled during that time should basically be zero (sorry, cannot find the source for the expected error anymore).

This should also mean the storage of data is much less of a problem, because if I have a new absolute reference, I should be able to discard all the accumulated errors and start over.

More later.


Edmunds
 
Last edited:

BESQUEUT

Senior Member
there could be absolute reference points out there quite frequently. Every crossing is, sure a reference point and can have a stop line an infrared 'ID station' and other markers. Some pot hole covers can be semi transparent and have infrared emitters underneath. Magnets can be hidden under the roadway and cars can be equipped with hall sensors to check their relative position against absolute to the tenth of a millimetre. And finally the 128 pixel array can see some features precisely enough for them to serve as an absolute reference.
Something like a white line on center of the road ? :rolleyes:
I have never pushed the limits and not even clearly and specifically defined what would be required and would not be enough
YES : start with that. What is exactly the challenge ?
 

edmunds

Senior Member
YES : start with that. What is exactly the challenge ?
First up.

Single axis Attitude or Relative orientation (d.) = gyro output (d./sec, 16-bit, two's complement) * sensitivity (d./sec, say 360/1000) * sample time (s, say 0.02s = 50Hz).

Correct?

Edmunds
 

BESQUEUT

Senior Member
YES : start with that. What is exactly the challenge ?
I mean for example :
1- Robot start center of road, with appropriate heading.
2- It travel whole circuit, line following.
3- Line is removed (or sensor deactivated)
4- Robot start center of road, with appropriate heading, same position as 1)
5- How many cm/mm does it have to travel before "seeing" a refence point ?
6- How many time does it spend to travel to that point (IE what is mean speed ) ?
7- what is the road width and the robot width ? (IE what is the acceptable error ) ?
8- What is a reference point ?

Or maybe :
I want to use a gyrometer. What can I do with that and my robot ?
If this is the case, I can suggest :
The robot is 10 cm from the edge of a square white board, heading // an edge.
Mark where it is, and try going for a square travel to the starting point.
Start with a 20cm square, then more till the whole board.

When OK for that, post the video :p
 
Last edited:

BESQUEUT

Senior Member
sensitivity (d./sec, say 360/1000)
That is 0.36 deg/sec
Where did you find that specification ?
For LSM6DS3 I read :
Angular rate sensitivity : 4.375 mdps/LSB (When maximal angular speed is less than 125 deg/sec)
That is 0.004 deg/sec
But Gyroscope RMS noise in low-power mode(5) is 0.14 deg/sec
 

edmunds

Senior Member
I mean for example :
1- Robot start center of road, with appropriate heading.
2- It travel whole circuit, line following.
3- Line is removed (or sensor deactivated)
4- Robot start center of road, with appropriate heading, same position as 1)
5- How many cm/mm does it have to travel before "seeing" a refence point ?
6- How many time does it spend to travel to that point (IE what is mean speed ) ?
7- what is the road width and the robot width ? (IE what is the acceptable error ) ?
8- What is a reference point ?

Or maybe :
I want to use a gyrometer. What can I do with that and my robot ?
If this is the case, I can suggest :
The robot is 10 cm from the edge of a square white board, heading // an edge.
Mark where it is, and try going for a square travel to the starting point.
Start with a 20cm square, then more till the whole board.

When OK for that, post the video :p
Thanks, I will try to do both, answer your questions as this could bring some more ideas on the table and also try a straight line and possibly a square when that works :). Until that, however, I need to sort out power and motor control, which was, lets say, jury-rigged for line follower. Not difficult and I have done it many times before, but it will take some half a day of work.

1- Robot start center of road, with appropriate heading.
YES.
2- It travel whole circuit, line following.
YES.
3- Line is removed (or sensor deactivated)
YES, deactivating sensor is far easier for testing ;)
4- Robot start center of road, with appropriate heading, same position as 1)
SI. I was even thinking it would follow some piece of line to centre itself and then switch over to gyro based steering.
5- How many cm/mm does it have to travel before "seeing" a refence point ?
If I could achieve 2000mm of reliable autonomy, this would cover 98% of potential applications.
6- How many time does it spend to travel to that point (IE what is mean speed ) ?
Depends on the speed. 90km/h would be 0.28m/s SCALE speed. 10km/h would be 0.03m/s.
7- what is the road width and the robot width ? (IE what is the acceptable error ) ?
'Robot' is 26mm wide, the road is min 40mm more often 50mm, wider in bends, so two max length cars can pass each other at full speed.
8- What is a reference point ?
There are several things that are done and several more that could be done. Describing them in too much detail would take this thread off topic. For the purpose of the exercise, lets just say we can get at least two lateral points at a known longitudinal distance, so we can get lateral and longitudinal position and also orientation with precision. Lets assume we can get them fast with no effect on the rest of processing.


Edmunds
 
Last edited:

edmunds

Senior Member
Picaxe timing won't affect slotted wheel encoders,they are absolute and you can use pin interrupts for counting the slots but wheel encoders are not much use on bends just straight lines. You could use a RPI and quickbasic if you want trig,memory and speed or if you want to use a pic then gcbasic. Right tools for the job,etc. http://gcbasic.sourceforge.net/help/_trigonometry_sine_cosine_and_tangent.html
Stan, thanks for the links. Interesting, but if the only thing I need trigonometry for is direction cosine matrix out of which I really care about one vector, because I'm only interested in rotation about a single axis, then I have a hard time believing I should switch platform because of this :)

Edmunds
 
Last edited:

edmunds

Senior Member
So you can understand why (past first second) your mm tracking will be many more accurate than accelerometer and why you can forget it...
This actually gives some nice points on why accelerometer could be interesting. Not for linear velocity/distance, but for controlling gyroscope drift. Sensor fusion is the buzzword they use :).

Edmunds
 

edmunds

Senior Member
Encoder counting does not involve time : you only have to not miss any pulse.
degrees/s involve time.
If the timing is not accurate (and it's very difficult to have an accurate timing with a Picaxe) the rotation measurement will not be accurate.
Even more if the Picaxe is doing few things at the same time...

Example :
you measure 100°/s during 0.1 s ==> so rotation is from the Picaxe 10° (OK for that ?)
But actually, time is 0.15s ==> rotation is actually 15°

Do that every 0.1s ; what is the error after 10 s ?
Ok, I understand what you are saying.

100 d./s is a lot, I think. The cars cannot turn that fast, but to be honest, I cannot say how fast can they, so this is a bad argument. Anyway, 50 deg off in 1s is a bad prospect.

The device has 8 kbytes of FIFO buffer. That is up to 512 16bit samples for single axes operation. This is one of the reasons I selected it. So, timing is not my problem. It is done for me. My problem is figuring out what exactly needs to be done to the data knowing the frequency the gyro is set to operate at when it is read in comparison to the speed I'm travelling with. The same route could be travelled very slow and very fast, but the same input route data should be used. Or am I totally mistaken with this?

Edmunds
 
Last edited:

edmunds

Senior Member
- same for a magnetometer
It is not impossible to add magnetometer to the soup. However, there are changing magnetic fields at play on model railroads. One could 'map' his layout before installing some source of magnetic field near the road that would totally send the data to the bin. Things like servos and even more so - electromagnetic points could all have influence depending on their state. I have not tried it though in real life, these are only assumptions. Maybe I should at some point. However, gyrothing, whatever a good name for it is, is on my table in several forms, so that is what I can try now.

Edmunds
 

AllyCat

Senior Member
Hi,

I'm not up with the latest technology, but IMHO inertial navigation won't work at the scale and speeds that you're using. Also, a figure that I noticed in one of the data sheets for a gyro was (to paraphrase) "drift in zero angular direction due to temperature change". It was typically 0.05 degrees per second per degree C. For 10 degrees C change, that's half a degree per second or 30 degrees in a minute. But perhaps combining a gyro compass with a magnetic compass could give adequate results (since they each have their particular weaknesses and strengths)

wheel encoders are not much use on bends
They are if you have one on each wheel! It's exactly what full-sized car navigation systems used until the GPS system became available. Maybe they still use it in tunnels, etc., since the sensors are probably available in the Anti-Lock Brake system anyway. It's what I'd try as an autonomous solution for the OP's application. Certainly quite accurate "DIY" trigonometric functions are possible with a PICaxe, using a lookup table. But I think those in the X2s are probably rather too "basic" (with a small B).

If you want an off-the-wall idea, how about a "GPS-style" ultrasonic navigation system, with three ultrasonic transmitters representing satellites. The time-of-flight calculations shouldn't be too difficult, with the "satellites" stationary and the speed of sound almost a million times slower than radio waves.

Cheers, Alan.
 

edmunds

Senior Member
Yes, that is one system out of two out there, but I have better than both in place today all based on picaxe. However, if you study it carefully, the cars are steered with a 'magnetic arm'. The rest is just smoke and mirror. There is no real positioning and the 'satellites' are prone to various errors and glitches. On top of that you have to install so many to cover a large area. And the fact the car is a dummy and all processing is done on a central machine makes this impossible to scale. Two cars are fine, three are probably ok, nobody has tried 10, let alone 100.

Exactly the magnetic arm part is what I want to get rid of. And yes, I know there is probably a reason nobody has done it so far and most likely the reason is it is bloody difficult :).

Edmunds
 

edmunds

Senior Member
I'm not up with the latest technology, but IMHO inertial navigation won't work at the scale and speeds that you're using. Also, a figure that I noticed in one of the data sheets for a gyro was (to paraphrase) "drift in zero angular direction due to temperature change". It was typically 0.05 degrees per second per degree C. For 10 degrees C change, that's half a degree per second or 30 degrees in a minute. But perhaps combining a gyro compass with a magnetic compass could give adequate results (since they each have their particular weaknesses and strengths)
I realise this might be a wall I cannot climb. However, I could not figure out how to calculate this reliably upfront, so I thought this would be easier just to try and see. If I play with my phone a bit, it seems to be sensitive enough and I cannot know if it is using the device at its most sensitive setting. And I cannot know how many devices each piece of software is 'fusing' to give me the movement.

It could be as little as a day away because I sorted the power, the main engine and most of the chassis. I will now try to convert d/s into degrees on my desk and see if I can integrate accelerometer data into gyro data to compensate for long term drift and get some sleep :D.

Edmunds
 

edmunds

Senior Member
Dear all,

Tried the gyro raw output conversion to degrees just for the fun of it. It seems to work (says around 90 for around 90 degree move), but drifts like crazy. Not useable like this for anything. Will try accelerometer integration into gyro result tomorrow.


Cheers,

Edmunds
 

BESQUEUT

Senior Member
Ah, ah, ah, ah ah, ah !

see if I can integrate accelerometer data into gyro data to compensate for long term drift :D
This is the best Joke I read for years !


This is simply impossible.

Earth gravity is an acceleration, so measurable with an accelerometer (OK for that ?)
Supposing an orthogonal spatial system of axes and Z being vertical.
You can use accelerometer to measure absolute X and Y rotation (and then compensate for long term drift...)
But Z is colinear with earth gravity !

==> no chance to measure or compensate anything on Z rotation....
 
Last edited:

BESQUEUT

Senior Member
It is not impossible to add magnetometer to the soup.
Compensated magnetometers are easy to use but (very) expensive.
Non-compensated magnetometers are quite difficult to compensate with a Picaxe, but not impossible :
head-tracker/page18
Look at #155 for links, #171 for theory and #180 for code...

But I think that you can use non-compensated magnetometer quite easily if sensor is strictly horizontal.
 
Last edited:

edmunds

Senior Member
This is the best Joke I read for years !
Well, it is not that much of a joke, it is just something I did not know :). Anyway, there seem to be some workarounds and I'm trying to learn about those.

Meanwhile, I have managed to stabilise the gyro alone a lot using internal filters and different operation modes and speeds of the device. While I was out in the snow with kids, the thing clocked some 120'000 reads and while there is some noise (or tiny vibrations of my desk or even the building), there is no steady state drift - the values jump a little around zero, but zero has not shifted anywhere. What I can see is, that it is still a little slow to settle back to zero, however. So initially, it will always stabilise at some +5 degrees, not zero and slowly slide towards the 0 in some 10 or 20 samples. This does not look like something I could not work with anymore, if I learn to operate with average of, say, 10 samples and the averaging can be done in hardware or just very fast on picaxe. Will work towards this now.

Edmunds
 

AllyCat

Senior Member
Hi,

"You mean something like this? https://www.car-system-digital.de/de/"

... if you study it carefully, the cars are steered with a 'magnetic arm'. The rest is just smoke and mirror.
My German is not at all good, but IMHO an ultrasonic "GPS-like" system could be possible, unless the circuit is very large. Probably possible with four "satellites" at the corners of an area of 100m2 ? I don't know how many of the "exotic" GPS techniques would be required, but (AFAIR) the transmitted data rate is 50 bits per second and the receivers operate at around 20 dB (100 times) below the noise level.

The GPS system is totally autonomous (like broadcast radio), so any number of receivers can opearate at the same time. But it would probably take more than a few hours to develop. ;)

Cheers, Alan.
 

BESQUEUT

Senior Member
IMHO an ultrasonic "GPS-like" system could be possible, unless the circuit is very large. Probably possible with four "satellites" at the corners of an area of 100m2 ? I don't know how many of the "exotic" GPS techniques would be required, but (AFAIR) the transmitted data rate is 50 bits per second and the receivers operate at around 20 dB (100 times) below the noise level.
Lot of math, and time critical. IHMO, not doable with a Picaxe...
 

edmunds

Senior Member
Hi,



My German is not at all good, but IMHO an ultrasonic "GPS-like" system could be possible, unless the circuit is very large. Probably possible with four "satellites" at the corners of an area of 100m2 ? I don't know how many of the "exotic" GPS techniques would be required, but (AFAIR) the transmitted data rate is 50 bits per second and the receivers operate at around 20 dB (100 times) below the noise level.

The GPS system is totally autonomous (like broadcast radio), so any number of receivers can opearate at the same time. But it would probably take more than a few hours to develop. ;)

Cheers, Alan.
Well, I have not looked into this so much as I have no particular interest and thus no understanding of ultra sound stuff, but guys at Miniatur Wunderland have reportedly invested manyears and millions of euro actual cash in trying to implement such a system. The result is, where it cannot be avoided, there is a human operator hiding behind a mountain controlling a vessel/vehicle with a normal RC control. What really works and how hundreds if not thousands of cars by now run on the layout is same old steering magnet approach.

That said, they stopped the project years ago and there are much more powerful devices available today in the scale required. What I have heard is the main problem is distortion due to human speech, odd bag zipper opening and things like this. Faller had massive problems and a delay of about 5 years just because the system refused to work in exhibition halls due to echoes. It worked fine in small rooms, but could not be demoed in trade fairs, so they could not get it to market. It seems to be working now (will check in two weeks myself in Nurnburg Toy Fair), but I don't know how they sorted it.

Gyro output now seems so reasonable on the desk and I have figured out how to use FIFO buffer, so I'm trying to put everything in the car to attempt @BESQUEUT's 20cm square idea.

Edmunds
 
Last edited:
Top