Propeller autopilot - newbie help
Joshua Siegel
Posts: 51
Hi everyone,
I'm a newbie to the propeller but OK with basic stamps and I've tinkered with the SX48 (thought I must admit I never did like it).
I had a question about feasibility for a project I'm trying to hammer out fairly quickly. I want to make an autopilot system utilizing a 5Hz GPS, accelerometers, and some potentiometers. I have the layout and logic in my head, but not a clue as to how to program in spin or even if I'm approaching the use of cogs properly - some guidance would be greatly appreciated.
What I have laid out so far to code is as follows:
Cog 0 - PC in/out (w/ interrupts)
-Take input string from PC in form of:
PWM1,PWM2<CR><LF>
and update variables for each in each cog
-Take variables from other cogs and output in form of:
LAT,LONG,VELO,ACT_HEADING,COMP_HEADING,ACCEL1,ACCEL2,ACCEL3,POT1,POT2
Cog 1 - GPS in/out (w/ interrupts)
-Configure GPS at startup (serial out, send a few commands)
-Read and parse NMEA to update LAT,LONG,VELO,ACT_HEADING (this is at 5Hz)
Cog 2 - read analog sensors
-0-5V accelerometer (x 3 axes) (ACCEL1,ACCEL2,ACCEL3)
-0-5V potentiometers (x 2 pots) (POT1,POT2)
Cog 3 - read digital sensor
-HM55B compass x1 (COMP_HEADING)
Cog 4 - PWM out
-using PWM1,PWM2 values from PC. eventually may be a PID process - this should be easy to implement once the rest comes together
EVENTUAL:
Cog 5 - Video out with vitals.
Cog 6 - log waypoints to SD card.
Does this seem reasonable to ask of the propeller? I CAN share variables across cogs, right? Any tips on programming for beginners? I know there are some objects for the HM55B and some generic NMEA/video out/analog inputs, but I've no clue how to modify them for my applications. I'd like to have a prototype running fairly soon after setting up the board - is spin friendly enough for new users?
Thanks to all, and a happy new year!
I'm a newbie to the propeller but OK with basic stamps and I've tinkered with the SX48 (thought I must admit I never did like it).
I had a question about feasibility for a project I'm trying to hammer out fairly quickly. I want to make an autopilot system utilizing a 5Hz GPS, accelerometers, and some potentiometers. I have the layout and logic in my head, but not a clue as to how to program in spin or even if I'm approaching the use of cogs properly - some guidance would be greatly appreciated.
What I have laid out so far to code is as follows:
Cog 0 - PC in/out (w/ interrupts)
-Take input string from PC in form of:
PWM1,PWM2<CR><LF>
and update variables for each in each cog
-Take variables from other cogs and output in form of:
LAT,LONG,VELO,ACT_HEADING,COMP_HEADING,ACCEL1,ACCEL2,ACCEL3,POT1,POT2
Cog 1 - GPS in/out (w/ interrupts)
-Configure GPS at startup (serial out, send a few commands)
-Read and parse NMEA to update LAT,LONG,VELO,ACT_HEADING (this is at 5Hz)
Cog 2 - read analog sensors
-0-5V accelerometer (x 3 axes) (ACCEL1,ACCEL2,ACCEL3)
-0-5V potentiometers (x 2 pots) (POT1,POT2)
Cog 3 - read digital sensor
-HM55B compass x1 (COMP_HEADING)
Cog 4 - PWM out
-using PWM1,PWM2 values from PC. eventually may be a PID process - this should be easy to implement once the rest comes together
EVENTUAL:
Cog 5 - Video out with vitals.
Cog 6 - log waypoints to SD card.
Does this seem reasonable to ask of the propeller? I CAN share variables across cogs, right? Any tips on programming for beginners? I know there are some objects for the HM55B and some generic NMEA/video out/analog inputs, but I've no clue how to modify them for my applications. I'd like to have a prototype running fairly soon after setting up the board - is spin friendly enough for new users?
Thanks to all, and a happy new year!
Comments
I think the prop is perfect for your project. If you have basic experience, spin is simple to change to. I have worked with nmea and it is simple to use for parts of the app.
Do you have a source of co-ordinates for airports by any chance? I am going to make a cheapy gps and flight instrument.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mosquito: An animal which buzzes in your ear and never stops. He may byte you, he may nibble you, but you will know you were bit.
Technologically challenged individual, Please have pity.
as for airport coordinates, some software like the software that comes with DeLormes Earthmate GPS should be able to import/export coordinates - if not, try google maps, i bet you can use their info.
take your time. To use the Propeller efficiently requires a little bit patience and experience.
You have defined four parallel activities (processes) above. Yes, all these processes can communicate through the HUB.
It's now to decide:
- what can be done in SPIN (preferable, but rather slow)
- what needs coding in assembly (due to hard timing constraints< 100µs)
- what can be implemented with timers/counters, which will release timing so much to allow SPIN programming again
This needs good understandning of all mentioned three concepts.
There are many objects that can be useful to you (with modifications!), but it is sometimes simpler and more rewarding (and even faster!) to recode it, stealing just the ideas (and "a little bit" of the code)
··· I am wondering if you could get the accuracy needed to use a gps for an r/c. Even if the accuracy was say 3 meters thats a pretty wide area to be off in a small car.
· I would be looking for a database to load into vbasic rearrange for my purposes, mostly reduce size and load into the·SD chip for the prop to use. Name, Lat , long, altitude, runway dirs.
Get the prop, you will love it
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mosquito: An animal which buzzes in your ear and never stops. He may byte you, he may nibble you, but you will know you were bit.
Technologically challenged individual, Please have pity.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
IT's totally do-able, but it won't work...
...without some good logic. AND of course I don't know exactly what you are trying to do... an auto pilot ... to traverse what?
If you take your GPS out in your car you will notice that every once in a while it isn't off by 3 meters... it is off by a city block and slowly inches its way back. I don't know why this happens, it just does. Same with the other GPS variables. So, you pretty much have to monitor your output, cross compare your sensors and reject the bad data.
I don't think you need to worry about Kalman filters, but you are going to have to figure out when you have bad data.
The 2D accelerometer will work for short runs... it is an amazing little device. Just zero it out every time you stop. On the software side you have to figure out what you are going to do with the 4th decimal place in the data.
I haven't tried the 3D yet.
I think you are going to want to add object avoidance ... how about a pinger or two?
Rich
· With the new waas feature the acurracy of the gps has been tremendously improved however it is only available in the U.S. as far as I know. A gps on the ground that is waas enabled would not work as the signal is from a ground based system so line of sight is impossible.
· I may be completely wrong but that is the info I have stored in current grey rom.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mosquito: An animal which buzzes in your ear and never stops. He may byte you, he may nibble you, but you will know you were bit.
Technologically challenged individual, Please have pity.
There had been "specifications" when constructing the GPS system around some twenty years ago:
- one imprecise commercial sub system (C/A)
- one very precise military sub system (P/Y)
Alas, it turned out in operation later that the commercial system was not at all imprecise
GPS is not used as a primary navigation system for non-military safety critical areas as in aviation e.g. , because SA can again be reactivated without notice.
"Differential GPS" is a nice trick to compensate for all kinds of noise - including SA - by just comparing a well known (terrestric) position with the computed one (a tiny "Kalman filter" as it were
By such an ingenious idea (and no cost at all compared to the investment for the satellite system) commercial applications suddenly became more precise than the (uncorrected) military data.
The correction signal had been transmitted by local long wave radio, thus needing an infrastructure... The recent development uses satelites: WAAS in North America, EGNOS in Europe, and MSAS in Japan.
The main improvement for accuracy - compared to terrestric DGPS - comes from the consideration of actual ionospheric conditions. It is said you can now pinpoint nearly up to the meter...
Very exciting!
Edit: SA.... I just read SA (= making it worse) was turned-off for the first time during the gulf war - in contrast to what you would have expected. As there were not enough military receivers available the troops had to rely on the GI's private pocket receivers
Post Edited (deSilva) : 1/2/2008 2:24:40 PM GMT
This TOTALLY DOABLE. There are several projects going on now for Propeller controlled navigation (including mine
While I agree that this won't be something that can navigate within inches based on GPS, there is a lot you can do with only GPS. If this is an RC vehicle, start slow and work your way up.
I have my prototype Come-Home system for my RC plane. While far from perfect, this is my failsafe when RC control goes down or out of range. There are a couple of projects that are here for insight:
GPS Parsing: Perry get full marks here. This is the best acquire and parse routine I've used for the Prop for a passive GPS feed (like from a Garmin sending NMEA strings). This module to look at is GPS_IO_mini.spin.
obex.parallax.com/objects/225
Radio Control Receiver Input to a Prop. this is my old code. It can use improvement and feel free!
http://forums.parallax.com/showthread.php?p=639179
PNav www.PNAV.net This is a plug for my website, where I keep the latest code, test videos, etc. there for my Propeller Navigator project. Its at the bench/alpha stage, but does most of what I want. Share and share alike.
Add an IMU Once you get into it, you can add an IMU - Inertial Measurement Unit. This adds sensing for motion locally, not with a GPS, but accelerometers. Jason Wood contributed this code - this is way beyond me today! diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A17208
Also have a look at Graham Stablers thread Index (it's stickied). He cataloged a nice selection of projects that apply. http://forums.parallax.com/showthread.php?p=609066
LAST - Don't let this list overwhelm you. I found it can be like drinking from a firehose, so define what you want to do step by step and you'll make great progress.
Paul
Post Edited (Paul H) : 1/2/2008 9:52:20 PM GMT
I'm not worried about "inches" resolution - 10 feet would be perfect. I do have an array of 11 sonar that I will eventually use for object avoidance, but that's way down the line.
Paul, your website was what convinced me to buy the prop - good to see you on here - I may have some more specific questions for you later [noparse]:)[/noparse].
I've actually done similar projects before using a laptop as the primary processor. The difference now is that I want to have a single serial data stream to the computer and the GPS updates at 5Hz instead of 1Hz, letting me go a bit faster than my old power-wheels and r/c tank projects (both were drive by GPS and had basic object avoidance. I want to try it on a go-kart now that 5Hz GPS have become mainstream).
My thought, at least for the initial run, was that I wanted a data-logger which I could effectively record and play back. Find the nearest location on the PC from an ordered list of lat/long, and set throttle, brake, and steering to match where they were when it was human controlled. I'd essentially "read off" all the PWM values. The accelerometer is simply there for future-proofing, when I want some more feedback to help improve accuracy.
What I'm leaning toward now as far as coding goes is actually using a BS2 to handle all the analog inputs (I happen to have one sitting around). This will read a string to the prop, will will also read NMEA from my GPS. That frees up more cogs for fun stuff later on, and I think the BS2 can keep up with 5Hz with six analog sensors and an HM55B. Can the prop handle three simultaneous PWM values on a single cog? What about a PID process for each? I figure that since I'll be using motors and not servos (at least for steering), I could use some freed up processing horsepower.
Drinking from the firehose? I go to MIT - this is a relaxing break [noparse]:D[/noparse] Gotta keep the mind sharp, though, and this is really what I love to do!
edit: my GPS is WAAS enabled and DGPS capable. If only receivers were cheaper [noparse]:([/noparse]
My next question is, is there a multi-channel ADC I could use at ~10-20Hz to get data from all six analog sensors (0-3.3V) I have? What about nine, down the line (if I add a gyro, which seems like a fun little addition)? Bear in mind I've never used an ADC before (and wouldn't want to, except I feel like rctime is a huge bottleneck for the cog, especially with 6 sensors). Would an I2C ADC work, like http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3397 ?
I totally scrapped my first .spin program earlier today and I will try to recode the basic functionality tonight. Hard to debug without having all the important bits, but I might have something usable by the time my things arrive at least. I will post what I get once I'm happy or totally confused by it. Thanks!
-Josh
Post Edited (Joshua Siegel) : 1/11/2008 3:00:53 AM GMT
I'm using an FV-M8 5Hz gps that outputs all the standard strings. I'm interested in lat, long, and velocity from it so I figure I'll use GPRMC. I looked at the GPS to VGA object and it uses a ton of cogs - one for the VGA, one for the GPS, one for a full duplex uart. Taking out the VGA, I'm still looking at a minimum of two cogs. That seems unnecessary. I was able to combine the two into a single cog, but have no idea how or if it will function, since I don't have the hardware on hand yet.
My question is, why would I use the GPS object provided if I can use the BS2_Functions object and use serin (it seems like a 49 character limit is the only issue)? It only uses one cog. Is the benefit of a uart that it functions more like an interrupt, so I dont miss anything? Will that be a problem with only one string output at 5 hertz? Also, would serout then work to configure my GPS? I don't want to waste my time on something that I'm going to have to scrap anyway, but it seems like two cogs is a lot of processing for what should be a simple task.
I've attached my (butchered) version of the GPS object on this site. I don't expect anyone to look at it, but it might give you some idea of how new I am with spin [noparse];)[/noparse] . I'm assuming that, for setting up the gps, I can use the txbyte from the full duplex driver, add that in, and send my commands during the start routine?
Post Edited (Joshua Siegel) : 1/13/2008 4:13:18 AM GMT
Have a look at the "Outback Challenge" rules regarding failsafes.
A dual prop autopilot with redundancy would be cool. 16 cpu's should be enough[noparse]:)[/noparse]
To get more accuracy, include a GPS on the remote control transmitter, you can then apply differential corrections.
This helps with takeoffs and landings.
Pressure sensor for barometric/altitude control, one on the base will compensate for weather changes on long missions.
Google "spider" GPS networks, these are base stations that transmit corrections, usually for survey purposes and they cost per useage.
Coastguard transmitters offer corrections as well.
A good autopilot will have 3 axis accelerometers, 3 axis gyros, 3 axis compass and pressure sensor.
These will need processing usually with Kalamn filters.
SPI sensors are available so no ADC is needed. Low cost analog sensors could be processed witha AVR, PIC or MPS430 micro first.
Try to find 3v3 sensors to save 5 to 3 volt interface issues.
Light sensors/UV sensors have been used for horizon detection, good for attitude control and gyro calibration.
It would be best to test all these and your software on a water/land based vehicles first.
Unless you have a nice big safe flying area. Hmm wonder if I could program one to fly in formation with my paraglider?
Flocking software?
A balancing robot is a good step for testing software and lots of fun.
Hmm wonder if anyone has done a monster truck balance bot?
A vision system or laser could be used for auto landing.
I would have said this would have been beyond the prop until someone recently showed it could do simple vision processing.
Prop 2 is going to be great.
Gavin
++
Joshua, this requires your understanding! The COGs in the Propeller can be used for many things:
- Upload machine code (only way to run your own machine code.. when you have more than 500 instructions, you need a third one, e.t.c.)
- Parallel processing ("threading") for simplification of some algorithms, and for boost of throughput
- warranted and fast response time
Whenever you need one of those features, you need a COG. Is has been observed many times that the Propeller has to few COGs for many real life projects.
If and how it is possible to combine things in one COG, or how to distribute things between the COGs is your work as system designer. Someway telling you how to do it will spoil ALL YOUR FUN. What reamains is some dirty underpayed "coding"
And: Never confuse response time and throughput!
When you want to catch the NMEA string send every second, then you can easily WAIT one second.. but can you? If not how fast can you poll? At 1200 baud you have to do that at 40µs, which are 6 to 8 SPIN lines (or 800 machine instructions. )
Post Edited (deSilva) : 1/13/2008 4:11:18 PM GMT
by no means am I asking anyone to do my dirty work. I'm just curious as to why I need a full uart instead of using shiftin and then parsing like the old .bs2 examples. I do understand the use of cogs for threading, though maybe not exactly WHEN a new one must be conjured up, since I have never used the board before.
I guess the uart/shiftin discussion comes down to speed. deSilva, are you sure that 1200 baud is 6 to 8 spin lines? I need to use 38,400 baud! Somehow I feel like there may be a mistake somewhere. Even a .bs2 can capture and parse NMEA data at 4800 baud (on a single core). Why couldn't I simply port that code to the Propeller?
My only concern is that I'll run out of cogs with what I want to do, and the whole reason I got the prop was for a single chip interface. Thus far, I'm planning:
Cog 0 - initialize other cogs. Handle I/O to/from PC (this might need a uart but I'm trying to use shiftin/shiftout)
Cog 1 - Data from compass and accelerometer (both require shiftin/shiftout coded in assembly - I merged the two objects on Obex because I only need 5-10Hz updates)
Cog 2 - Data from ADC (more shiftin/shiftout - could conceivably merge with the compass/accelerometer)
Cog 3 - PWM output (32v3 servo object)
Cog 4 - GPS i/o (trying shiftin/shiftout)
Cog 5 - Video
Cog 6 - SD card
If I drop the non-critical features - SD card and video, namely - I can have a full uart for both GPS and the PC, but then I worry about future expandability (how long until the Prop II is out? [noparse]:D[/noparse])
Lastly, when sending commands (if I use a full uart), can I simply send it one byte at a time? tx("$") tx("P") and so on?
To keep it short: The Propeller has neither something like SHIFTIN or SHIFTOUT nor UARTs. These are all fictions on the Propeller, some of them bundled and pre-programmed in some object for your convenience.
However BS2 and SimpleSerial are for simple projects only and fpr your education as how to accomplish things.
Things are: Catch the bits on a serial line (or make them)
The propeller is able to catch or generate 2 Mbit per sec per COG, with special care twice as much.
However this needs programming, not using SPIN based off-the-shelve functions.
In many cases you need considerably less and when its 100 times less you can stay with SPIN. it its only 10 times less you can choose a mixed imlementation with only a few asembly lines.
It is no problem at all to receive serial input from - say - 20 lines within one COG... It will need 6 instructions to check and store the signal level, cycling through 20 lines is 120 instructions = 6 µs = 160 kBit/second for each of the 20 lines.
Buffering the received bytes will take some some, so mayby 80 kBaud is more realistic with 20 lines to check from one COG.
However this is by no means possible by using the SHIFTIN or SHIFTOUT emulation.
Now to wait until tuesday to test my code!