um-FPU coprocessor and NMEA processing/parsing
billiam2536
Posts: 28
I need to take NMEA strings and parse them, and receive the Lat, Long, Time, Heading, and Altitude, each in there own variable. But I need as much as possible done on the coprocessor. Can anybody help me?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Working on getting money for autopilot project. Come check out my site if your interested in the project. Maybe go to the bottom of the page
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Working on getting money for autopilot project. Come check out my site if your interested in the project. Maybe go to the bottom of the page
Comments
2) What's wrong with GPS_Float_Lite that is in the Obex? Its quite parsimonious but handles NMEA data really well (you can comment-out any bits you don't need).
3) Whats with the FPU? I would have thought that integer maths in the Prop should be more than enough?
Hope this helps,
Hugh
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.
what do you suggest for getting the altitude? I mean, what kind of sensor rather than the GPS?
·http://www.parallax.com/StoreSearchResults/tabid/768/txtSearch/pressure/List/0/SortField/4/ProductID/591/Default.aspx
Alot of interesting information at the end of this build manual:
·http://www.ramseyelectronics.com/downloads/manuals/UP24B.pdf
Jim
If you are looking at an 'altitude hold' function on something that is not a model rocket, this should be more than good enough for an 'am I climbing' / 'am I descending?' type resolution. A heading-hold rate gyro will give you an 'am I turning?' and 'which way?' function and is in a format compatible with R/C servos.
IIRC, a lot of the DIY-Drones brigade use thermopile sensors to give a sky/ground sensor.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Working on getting money for autopilot project. Come check out my site if your interested in the project. Maybe go to the bottom of the page
Post Edited (billiam2536) : 2/18/2010 2:18:04 AM GMT
"If you think you need to use floating point to solve the problem then you don't understand the problem".
Now he might have bee saying that just to make us feel better about the lack of floating point support on the 16 bit minicomputers we were using for the project but lets see where this idea goes...
Your project involves long and lat coords. I.e. a position on the Earth's surface. The circumference of the Earth is pretty much 40,000Km or 40,000,000 meters. If we represent positions with signed 32 bit integers then we have a resolution of 0.018 meters or about 2 cm.
That seems to me that is quite enough resolution when working with GPS coordinates. You could do all your work in 32 bit ints.
If you are concerned about the loss of bits during calculations then bump it up to 48 or 64. Or reduce the size of your coordinates. Or assuming you are working in a limited area of the earth you can subtract an offset from all the numbers you work with and reduce the range considerably.
I'm sure you can find some integer or fixed point routines to do all this without a float chip, without a dedicated float COG and probably faster as well.
Now somewhere we have some cordic code for trig functions.
Don't forget, early scientific calculators did not have floating point in their hardware either!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I guess I'm just wondering how other people have managed to do it quite successfully without the co-processor. You can fit an *awful* lot of processing every second into 8 cogs. Maybe a little more description about what you actually plan to do might help us along a little bit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Working on getting money for autopilot project. Come check out my site if your interested in the project. Maybe go to the bottom of the page
If it was me, and I was sure I was going to run out of performance in 1 prop, I would first try overclocking it to 100MHz with a 6.25 crystal, and if that is not enough, strap on another prop with BeauNet and have a total of 14 cogs free and because you don't need to learn another chip it should be faster to develop.
Have you seen AttoPilot at http://www.parallax.com/tabid/252/Default.aspx. he does some amazing stuff with just 1 propeller.
If it was me, unless you have some pressing reason not to do so, I would open up my design to people in this forum. These guys are REALLY sharp and programming the propeller. It is really amazing on how much these guys can help, and they don't charge.
Just throwing in my 10 bits
Doug
As hinv says a COG is needed to communicate with the FPU chip. So it's just as well to use the COG for the FP functionality. Although I suspect fixed point might be a better approach.
Overclocking should not be on the table until you have really determined that you absolutely cannot manage with 80MHz.
I can see adding another Prop may be a no-no if this is an auto pilot for a small craft where weight is at a premium.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Working on getting money for autopilot project. Come check out my site if your interested in the project. Maybe go to the bottom of the page
propeller.wikispaces.com/integer_navigation
I had not time to finish it yet, but the basic idea of integer navigation is there. The only trig function you really need is atan2. sine and cosine tables are available in the propeller ROM, and for navigation purposes it is more than enough. If you check the forum you'll find a lot of stuff about cordic.
In my opinion altitude from GPS is not so bad, but you have an offset due to the difference between geoid and ellipsoid to be taken into aco(expletive). Some GPS units give you an altitude referred to the geoid.
If you feel like that please update also the wiki page with your findings.
Massimo
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Working on getting money for autopilot project. Come check out my site if your interested in the project. Maybe go to the bottom of the page
Strings, strings, strings!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.
"I don't really understand the integer math approach."
Well when one looks at a LONG variable in Spin or PASM one instinctively sees it as an integer. That's normal. Looks like it can only hold numbers like 0, 1, 2, 3 ... up up to (2 to the power 32) - 1.
But wait, what if we imagine the is a "binary" point between bit 0 and bit 1?
Then it is holding the numbers 0, 0.5, 1, 1.5, 2, 2.5 .....
Of course the maximum positive is now half as much.
Or we could imagine the "binary" point is between bits 15 and 16. I'll leave it to you to work out what possible numbers that can represent.
Don't forget we often use bit 31 as the sign bit to accommodate negative numbers.
So we see we can choose that those 32 bits represent numbers in many different ways, as integers or fixed point numbers or whatever. We just have to fix up our arithmetic routines to work accordingly.
The fact that lat and long are measured degrees has no significance. We can represent any quantity, degrees, feet, kilometers, whatever, in that same 32 bits within a certain range and with a certain resolution.
Arriving at accurate trig functions is a trick. CORDIC seems to be a popular approach. I was hoping CessnaPilot would join this thread. I seem to remeber he had some nice CORDIC maths under development.
Now consider. When we put man on the moon the Apollo Guidance computer only had about 30K instructions, ran at about 1MHz and for sure had no floating point hardware. Surely with the eight 32 bit processors of the Prop running at 20MIPS plus 32K RAM plus gigabytes of attached program store (SD card) we can tackle this guidance problem.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Can the uM-FPU be used for all AHRS calculations.
The DIY Drone guys seem to run their final DCM at 20Hz.
Can one cog be used to poll multiple sensors, another cog to run the comm with the FPU???
The Octopilot (seems to be the most developed prop project I have found please correct me if I am wrong) uses all 8 cogs but for the prop to be ideal beyond simply flying a small rc craft there needs to be at least one cog open for arbitrary experimentation.
I like the prospects of the propeller. 160 mips aught to be able to do what the ArduPilot does even with the new 9Dof (which is two Atmega328's total) board with plenty to spare.
Theres is some of us working on Quadcopter code. For example I have
1 thread reading sensors ~200/sec (3axis gyro/3axis acc/3axis compass/pressure)
1 thread running 3axis IMU including all maths ~65/sec
1 thread updating the ESC ~200/sec
So its doable to do it all in the prop.
Do you have any cogs open yet? Is the code open for review?
Post Edited (Jimmy_Ru) : 7/3/2010 12:37:43 AM GMT
I am currently completing a pcb which I will overclock to 104MHz for the Quadcopter thread. The pcb is 1.75"x1.75" and fits into a Hammond 1551R box. Currently I am unsure if it will have a tiny daughter board for the sensors (gyro, accel, compass, pressure - all I2C). Currently it has a microSD on the main pcb. There will be a connection for an external GPS (such as the Parallax PMB688 - the cheaper PMB288? seems to not be listed anymore). It will also be possible to connect other items including the ultrasonic sensor from Parallax for close ground work. See the thread Tim mentioned above.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
You can download free tools to calculate VDOP if you're interested in seeing how it varies. Or just look at the sample chart on this page:
freegeographytools.com/2007/determining-local-gps-satellite-geometry-effects-on-position-accuracy
If you think about it a little - when would altitude be the most accurate? When there's a satellite directly overhead. Then what are the odds of a satellite being directly overhead?
I don't know how much adding additional GNSS systems will help, but it seems like it might help. I would guess that in 5 years it will be common for smartphones and pnds to support at least GPS + Glonass. Hopefully this will trickle into GNSS modules. We'll see about Galileo. Positioning off of SBAS probably won't help with altitude - unless you're located somewhere where they are overhead. And I'm not sure how accurate it will be, and I would guess that autonomous GPS modules wouldn't support this in any case.
You feel right. There are some reasons to use an FPU with the Propeller. Namely
1. Speed
2. Accuracy
3. Fewer COGs needed
As for speed
=========
It is not a shame to use available resources with the Prop/FPU combination. It is economic. With the user defined functions FPU is able to make full WGS84 rotating Earth calculations at 250 Hz rate with high accuracy. See demo of an object. I did it with Float32 first. That was 4 times slower and less accurate.
Propeller based tactical grade 6DOF IMU uses 2 FPU to produce accurate ECEF coordinates without GPS at 200 Hz rate. See a post for FPU IMU code.
Full system will use 3 FPUs for GPS NMEA parsing and WMM2010 magnetic field calculations for accurate IMU/MAG/PRES/GPS sensor fusion with Kalman filters. (And it will use 2 Props...)
As for accuracy
============
The FPU is 2-3 digits more accurate with many functions than the Prop/FloatMath/32. I clearly demonstrated that in some posts.
As for fewer COGs
==============
You can easily modify the FPU_SPI driver to drive many FPUs parallel. The new version of the driver will have that feature. Not to mention FPU_I2C with PASM.
Prop is very fast with integer arithmetic. I wrote maybe the fastest PASM code for the 32-bit and the 8-bit multiplications and divisions (see Fast, Faster, Fastes Code series of threads). (E.g. more than 1 million 8-bits per sec). But integer arithmetic is not for navigation calculations as a first resort. When everything works correctly in floats, you may try it with integers to make it even faster (as in the TTL area), but that will use a lot of resources in coding and time. Fixed point is a good compromise. See SPIN_TrigPAck, the first Fixed- point arithmetic package for the Propeller. It is much faster than Floatmath. See demo object.
So, with FPU you can make faster, more accurate devices with fewer COGs.
Let us hope that Prop·II will make·all these considerations obsolete.
Cheers,
Istvan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Intentionally Left Blank