Greetings to all.
An introduction ....
If you should do a Google for "DIY Fluxgate Compass" or similar, you'll find that there are NO viable DIY projects that are concerned with the construction of home-brew sensors themselves, or with the writing of the associated software.
There are a huge number of patents, but none of these provide 'CookBook'-type instructions. Methinks this is a big pity, and so no prizes for guessing that this is what I'm currently working on !
I've come to the end of hardware construction and now is the time to consider the software. Although I have a background in 8085/Z80 assembly language programming, my Basic skills really never progressed much beyond the "Hello World" stage.
For reasons of power consumption, I intend using one of the Microchip PIC processors, but as I can't easily get my head around their instruction set, I've decided to use a PIC Basic compiler. For this reason it would seem to make sense that I write and de-bug the program using a PC-based Basic so that I can make use of the screen, and then port it across to the PIC once the wrinkles have been ironed out.
So - a couple of Q's ....
1. is there a .doc file anywhere of the 'F1-Help' info from QB ? Or is there a way of printing this info out onto hard copy ?
2. does anyone have a 'draw a circle' routine using Cartesian co-ordinates, and where the (0,0) origin can be shifted ?
3. can anyone advise how to distort the above routine into an ellipse ?
(as you can see - I'm bit short on the maths skills)
I guess what I really need is "an idiot's guide to polar and rectangular co-ordinate systems", so if anyone knows of one ...
'best, Colin
New member, new project (fluxgate compass)
Re: New member, new project (fluxgate compass)
1. Sorry, I couldn't get the help to work for me either.sae140 wrote:So - a couple of Q's ....
1. is there a .doc file anywhere of the 'F1-Help' info from QB ? Or is there a way of printing this info out onto hard copy ?
2. does anyone have a 'draw a circle' routine using Cartesian co-ordinates, and where the (0,0) origin can be shifted ?
3. can anyone advise how to distort the above routine into an ellipse ?
(as you can see - I'm bit short on the maths skills)
I guess what I really need is "an idiot's guide to polar and rectangular co-ordinate systems", so if anyone knows of one ...
'best, Colin
2. Why not use the circle sub? CIRCLE (x, y), R will draw a circle with a center at point (x,y) with a radius R
3. IIRC, the next parameter of the CIRCLE command is color. The two after that are the aspect ratios that make it an ellipse. So it's CIRCLE (x, y), R, C, A, B. (x,y) are coordinates. R is radius. C is color. A is horizontal ratio. B is vertical ratio. I think that's how it is in QB.
For any grievances posted above, I blame whoever is in charge . . .
-
burger2227
- Veteran
- Posts: 2466
- Joined: Mon Aug 21, 2006 12:40 am
- Location: Pittsburgh, PA
The following is the graphics circle statement:
Col and row are the center positions of the Circle. Radius is half the circle width you desire. Circles CAN be drawn partially off screen!
RadianStart and radianEnd are to draw arcs. Values range from 0 to 2 * pi (which are actually the same radian). Decimal point values OK. Negative radian start or end positions will draw lines to the center for pie charts.
Ellipses use the Aspect ratio. From 0 to .99 thicken the ellipse height. A value of 1 is a normal circle! Over 1 decreases the width. Values can range up to a 10 to 1 ratio with the radius value.
If you cannot access the QB Help, make sure that you are in the QB folder with Qbasic and the HLP files. QB can run anywhere, but it will only look for files and create files in the BAS file's folder once it is clicked on.
Here is my QB Tutorial: http://www.qbasicstation.com/index.php? ... &filecat=3
Go to the bottom of the list and download, unzip "Q-basics.zip" to a QB folder.
Ted
Code: Select all
CIRCLE (col%, row%), radius%, colour%, radianStart, radianEnd, aspectRatio
RadianStart and radianEnd are to draw arcs. Values range from 0 to 2 * pi (which are actually the same radian). Decimal point values OK. Negative radian start or end positions will draw lines to the center for pie charts.
Ellipses use the Aspect ratio. From 0 to .99 thicken the ellipse height. A value of 1 is a normal circle! Over 1 decreases the width. Values can range up to a 10 to 1 ratio with the radius value.
If you cannot access the QB Help, make sure that you are in the QB folder with Qbasic and the HLP files. QB can run anywhere, but it will only look for files and create files in the BAS file's folder once it is clicked on.
Here is my QB Tutorial: http://www.qbasicstation.com/index.php? ... &filecat=3
Go to the bottom of the list and download, unzip "Q-basics.zip" to a QB folder.
Ted
Please acknowledge and thank members who answer your questions!
QB64 is a FREE QBasic compiler for WIN, MAC(OSX) and LINUX : https://www.qb64.org/forum/index.php
Get my Q-Basics demonstrator: https://www.dropbox.com/s/fdmgp91d6h8ps ... s.zip?dl=0
QB64 is a FREE QBasic compiler for WIN, MAC(OSX) and LINUX : https://www.qb64.org/forum/index.php
Get my Q-Basics demonstrator: https://www.dropbox.com/s/fdmgp91d6h8ps ... s.zip?dl=0
burger2227 wrote:The following is the graphics circle statement:Code: Select all
CIRCLE (col%, row%), radius%, colour%, radianStart, radianEnd, aspectRatio
Sorry, that is it. I mixed up the number of start/stop and aspect ratio arguments.
For any grievances posted above, I blame whoever is in charge . . .
Thanks for the replies - appreciated.
I can call-up Help via F1 ok, but I personally find on-screen help difficult to work with, and I'd much rather have the same info in some form of hard-copy.
Ted - your Command Tutorial is really good - think I'll print out the relevant page as I come across each new command used and make up a loose-leaf file. Thanks.
Regarding the CIRCLE command: what I am trying to achieve is not the drawing of a circle 'per se', but the drawing of Cartesian (rectangular) coordinates onto a screen, to see if a circle is actually formed as a function of the processed data.
To explain further, (sorry about these 'wordy' posts): the simplest form of electronic compass is a 2-axis compass, where a pair of sensors are placed at right angles to each other, producing Sine and Cosine signals of the detected magnetic field, and in an ideal world if the ArcTans determined from these Sine and Cosines were plotted, then a perfect circle should result.
However, in the real world small magnetic anomalies create distortions of this perfect circle: ellipses (major axis at any angle) result, as well as a dislocation of the circle's centre away from it's 0,0 origin.
It is because of this loss of origin that the polar coordinates will be converted, stored - and then hopefully displayed - as rectangular coordinates.
Some pretty fancy mathematics (well above my head !) can then be applied to the distorted figure to create the necessary offsets to pull the circle back into shape and also re-locate it onto it's former 0,0 origin - which of course from a QBasic point-of-view needs to be in the centre of the vdu screen. It is the application of these offsets which 'calibrates' the compass.
When the program is finally located within the PIC micro, this calibration routine will be invisible to the user, and so I would like to demonstrate it in a 'before and after' manner by using a Basic program using example distortions. Equally important is that the running of such a calibration routine on a PC will also enable me to visually judge the effectiveness (or not !) of the employed method, as I understand there are several calibration techniques to choose from.
The CIRCLE command could certainly be used to provide a 'reference' circle to work to, but I can't easily see how it could be used to plot the incoming data. For now, using the PSET command would seem to offer the best solution.
I can call-up Help via F1 ok, but I personally find on-screen help difficult to work with, and I'd much rather have the same info in some form of hard-copy.
Ted - your Command Tutorial is really good - think I'll print out the relevant page as I come across each new command used and make up a loose-leaf file. Thanks.
Regarding the CIRCLE command: what I am trying to achieve is not the drawing of a circle 'per se', but the drawing of Cartesian (rectangular) coordinates onto a screen, to see if a circle is actually formed as a function of the processed data.
To explain further, (sorry about these 'wordy' posts): the simplest form of electronic compass is a 2-axis compass, where a pair of sensors are placed at right angles to each other, producing Sine and Cosine signals of the detected magnetic field, and in an ideal world if the ArcTans determined from these Sine and Cosines were plotted, then a perfect circle should result.
However, in the real world small magnetic anomalies create distortions of this perfect circle: ellipses (major axis at any angle) result, as well as a dislocation of the circle's centre away from it's 0,0 origin.
It is because of this loss of origin that the polar coordinates will be converted, stored - and then hopefully displayed - as rectangular coordinates.
Some pretty fancy mathematics (well above my head !) can then be applied to the distorted figure to create the necessary offsets to pull the circle back into shape and also re-locate it onto it's former 0,0 origin - which of course from a QBasic point-of-view needs to be in the centre of the vdu screen. It is the application of these offsets which 'calibrates' the compass.
When the program is finally located within the PIC micro, this calibration routine will be invisible to the user, and so I would like to demonstrate it in a 'before and after' manner by using a Basic program using example distortions. Equally important is that the running of such a calibration routine on a PC will also enable me to visually judge the effectiveness (or not !) of the employed method, as I understand there are several calibration techniques to choose from.
The CIRCLE command could certainly be used to provide a 'reference' circle to work to, but I can't easily see how it could be used to plot the incoming data. For now, using the PSET command would seem to offer the best solution.
-
burger2227
- Veteran
- Posts: 2466
- Joined: Mon Aug 21, 2006 12:40 am
- Location: Pittsburgh, PA
See Chapter 3 and 10 in my Q-Basics tutorials. They show how SIN and COS are used to draw circles. You have to also convert from angles to radians using them.
You could plot real values and compare them with a perfect circle.
Ted
You could plot real values and compare them with a perfect circle.
Ted
Please acknowledge and thank members who answer your questions!
QB64 is a FREE QBasic compiler for WIN, MAC(OSX) and LINUX : https://www.qb64.org/forum/index.php
Get my Q-Basics demonstrator: https://www.dropbox.com/s/fdmgp91d6h8ps ... s.zip?dl=0
QB64 is a FREE QBasic compiler for WIN, MAC(OSX) and LINUX : https://www.qb64.org/forum/index.php
Get my Q-Basics demonstrator: https://www.dropbox.com/s/fdmgp91d6h8ps ... s.zip?dl=0
Thanks Ted - appreciated.
Your 36_Q-Basics tutorial is impressive - looks like it contains just about everything I'll be needing.
I've only one query: if you take a look at: http://en.wikipedia.org/wiki/Unit_circle it can be seen that 0 degrees is located at '3 o'clock' and the incremental direction of rotation is anti-clockwise. That is also the case in the many navigation patents I've been looking at.
However, in your demo, 0 degrees is located at '9 o'clock' with the direction clockwise from there. Is this a peculiarity of QBasic, or is it simply a question of convention ? Any light you can shed on this minor point would be much appreciated.
Best regards, Colin
Your 36_Q-Basics tutorial is impressive - looks like it contains just about everything I'll be needing.
I've only one query: if you take a look at: http://en.wikipedia.org/wiki/Unit_circle it can be seen that 0 degrees is located at '3 o'clock' and the incremental direction of rotation is anti-clockwise. That is also the case in the many navigation patents I've been looking at.
However, in your demo, 0 degrees is located at '9 o'clock' with the direction clockwise from there. Is this a peculiarity of QBasic, or is it simply a question of convention ? Any light you can shed on this minor point would be much appreciated.
Best regards, Colin
I don't know if this stuff is of interest to anyone else, but just in case anyone's interested in how electronic compass calibration is performed, here's the current state of play at this end ...
After studying around two dozen patents from the hundreds devoted to this topic it appears that there are 3 basic methods which normally involve a 360 degree rotation whilst gathering data:
1) The most demanding are the advanced mathematical methods in which (for example) the centre of an ellipse (created from biased readings) is calculated from 4 peripheral points on that figure. There is at least one example in which continuous calibration occurs and for which an initial rotation is not mandatory. However, such methods are demanding on both the programmer's brain and the microprocessor's capabilities, and have duly been discounted for my current project.
2) The second method involves gathering 360 degree's worth of data, the resulting figure from which is then compared with a perfect circle and the differences stored in a look-up table which is then used to adjust subsequent readings. This technique is simple in concept, but requires a large look-up table if reasonable resolution is required: 360 x 2 byte words x 2 axes would require 1440 bytes for 1 degree resolution, or half that if stored as polar coordinates. So not impossible, but for now remains a second choice.
3) The third method involves the simple technique of determining Xmax, Xmin and Ymax and Ymin, when gathering the 360 degree data. It doesn't even matter which direction one starts from, or which direction of rotation is chosen, as long at the maximum and minimum X and Y coordinate readings of the sensors are identified.
Any offset (resulting from hard-iron distortion) is calculated as, Xoffset = (Xmax+Xmin)/2 , Yoffset = (Ymax+Ymin)/2 and the axis ranges from Xrange = (Xmax-Xmin) and Yrange = (Ymax-Ymin). Any difference between the Xrange and the Yrange indicates soft-iron distortion which results in an ellipsoid figure if the readings are plotted.
As the data is read-in, the X and Y offsets are applied, which centralises the figure which would result from 360 degree's worth of data onto the X0,Y0 intersection. Then, by applying the scaling factor as: Xdata * Yrange/Xrange and Ydata * Xrange/Yrange, it can be seen than the ovality of any ellipse is neatly returned to a circle - but as experimenting with QBasic has revealed, ONLY if the major axis of the ellipse lies on or near either the X or Y axis.
The worst case situation is when the compass readings produce a soft-iron distortion of 45 degrees with respect to the X and Y axes, when the ellipse is not corrected by this delightfully simple method.
I've still got to decide which method to choose, before beginning coding - I'll keep you posted.
Can't seem to get the images to display here - they can be seen at:
http://earth.prohosting.com/sae140/calib.htm
After studying around two dozen patents from the hundreds devoted to this topic it appears that there are 3 basic methods which normally involve a 360 degree rotation whilst gathering data:
1) The most demanding are the advanced mathematical methods in which (for example) the centre of an ellipse (created from biased readings) is calculated from 4 peripheral points on that figure. There is at least one example in which continuous calibration occurs and for which an initial rotation is not mandatory. However, such methods are demanding on both the programmer's brain and the microprocessor's capabilities, and have duly been discounted for my current project.
2) The second method involves gathering 360 degree's worth of data, the resulting figure from which is then compared with a perfect circle and the differences stored in a look-up table which is then used to adjust subsequent readings. This technique is simple in concept, but requires a large look-up table if reasonable resolution is required: 360 x 2 byte words x 2 axes would require 1440 bytes for 1 degree resolution, or half that if stored as polar coordinates. So not impossible, but for now remains a second choice.
3) The third method involves the simple technique of determining Xmax, Xmin and Ymax and Ymin, when gathering the 360 degree data. It doesn't even matter which direction one starts from, or which direction of rotation is chosen, as long at the maximum and minimum X and Y coordinate readings of the sensors are identified.
Any offset (resulting from hard-iron distortion) is calculated as, Xoffset = (Xmax+Xmin)/2 , Yoffset = (Ymax+Ymin)/2 and the axis ranges from Xrange = (Xmax-Xmin) and Yrange = (Ymax-Ymin). Any difference between the Xrange and the Yrange indicates soft-iron distortion which results in an ellipsoid figure if the readings are plotted.
As the data is read-in, the X and Y offsets are applied, which centralises the figure which would result from 360 degree's worth of data onto the X0,Y0 intersection. Then, by applying the scaling factor as: Xdata * Yrange/Xrange and Ydata * Xrange/Yrange, it can be seen than the ovality of any ellipse is neatly returned to a circle - but as experimenting with QBasic has revealed, ONLY if the major axis of the ellipse lies on or near either the X or Y axis.
The worst case situation is when the compass readings produce a soft-iron distortion of 45 degrees with respect to the X and Y axes, when the ellipse is not corrected by this delightfully simple method.
I've still got to decide which method to choose, before beginning coding - I'll keep you posted.
Can't seem to get the images to display here - they can be seen at:
http://earth.prohosting.com/sae140/calib.htm