Hi All,
Before posting an issue or a problem in the ArduRover Discussion Forum, please check the wiki table of contents, review the firmware release notes in the subforum, and search that subforum for existing answers to your question. Help avoid duplicate threads by finding other members with the same issue and their solution.
When formulating your post, use a descriptive title such as "rover will not navigate to waypoints in the Auto mode" (not "HELP!" or "Problem").
Please include the following information to help diagnose your query:
- Describe the problem you are having. What is the expected verses the observed behavior?
- Provide hardware information such as the brand and version of your autopilot, GPS, radio, and compass, as well as any other pertinent details about your rover setup.
- What version of the APM: ArdurRover2 firmware version are you running?
- For navigation issues, provide your tlog and/or dataflash log. Click here for instructions on retrieving a dataflash log.
TCIII
Comments
@KM6VV re: 2 GPS -- I thought that too but apparently not. I mentioned that we discussed that on diyrovers. Not sure if you saw my link. Here's the info:
https://groups.google.com/d/msg/diyrovers/C_FB2fqE3bA/ULbDyLr1ew0J
And the direct links to pages explaining the issues.
http://www.oreillynet.com/pub/a/wireless/2000/12/29/two_gps.html
http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=109246
I'm converting to grid coordinates onboard. It made some critical calculatons much, much, much faster (ie, fast enough to actually run at 100hz). I set a radius threshold for distance to waypoint; within it, the robot slows down. Another threshold initiates turning.
My robot relies on dual rear wheel encoders for distance and speed and it seems to be accurate enough. Heading accuracy seems to matter quite a bit more.
I don't yet have a good direct to measure accuracy/precision of estimated heading. All I have to go on is that running the 270m course several times in a row, the ending lateral error was around 1.5m-ish by eyeball compared to where it started (and should have finished). That of course doesn't tell the entire tale, but it did seem to be quite precise, driving very close to the same path each time. I'm itching to get more accurate testing than "eyeball" and "I think" and "seemed to" :)
I found the gps positions reported by Venus and SiRFIII weren't precise enough, or at least that the DR with heading/encoder was quite a bit more precise. I don't use GPS speed either but have plotted it alongside wheel encoder a number of times. I haven't looked at the charts in months but my recollection is that it wasn't bad, most of the time, but there were times when it would go wonky.
@Derek -- come to think of it, if you want high, absolute accuracy, then no, GE probably isn't the ticket, but I think it would help for us to qualify the statement "accurate ground working positions" a little.
Also, the question is not only how accurate but also how precise whatever solution is.
In my case, as long as GE is sufficiently precise during a given mission, then accuracy should be irrelevant--but... the big thing I forgot to mention?
My robot uses dead reckoning from a starting point selected in GE referencing a physical landmark (like a manhole cover or such). That's what cancels any static GE error. (Any higher order error would manifest as imprecision then). Of course that assumes sufficiently accurate orientation in GE.
Dead reckoning will help (in my case gps heading & gyro fused along with distance). Fusing in accurate GPS position information, however infrequently, will surely help.
Next step for me is to improve measurement accuracy (as are others on diyrovers hence the discussion I linked to) so I can get a better handle on errors, causes, fixes. The robot was precise to 1.5m-ish, but there's some oddness I still have to track down.
@CarlT : yes, I believe it was one of the 2012 AVC competitors that tried this. Unfortunately I have no information on the results.
@Derek : I've historically tested against Google Earth and found there aren't constant offsets even for a single mission. It really depends on what satellites come in and out of view, what multipath interference occurs and where, and such things.
On the Google Earth topic-- GE isn't perfectly accurate to reality but because I set waypoints in GE according to on-the-ground markers, I figure the error cancels out, provided any GE to reality error remains the same for a whole day (during the AVC) which I've observed to be the case on many, many individual days of testing. (It really only seems to change occasionally)
We had a discussion on DGPS over on diyrovers on accurately locating one's rover, and getting into DGPS, diy DGPS, and other fun -- diyrovers discussion in case it is of interest.
DGPS is beginning to be used in smaller vessels, especially in survey work environments.
Would the offsets calculated from running a predetermined course vary with atmospheric or timing conditions? I had discounted that as practical only when always operating in the same region.
Differential GPS (D-GPS) is an interesting option from the hobbyist level - while certainly theoretically possible, a lot interdisciplinary problems would need to be solved - primarily coding some fancy math that fits your hardware setup precisely. If you take the time to try and tackle the problem, I'd be interested to know.
One commercial option is C-Nav DGPS (full disclosure, this is a branch of the company I work for - hence my familiarity.) It is a subscription based service, and obtains accuracies on the order of 10cm (or better.) Obviously such a service might be overkill for most hobbyist level financial commitments. If you are at all interested: http://www.cnavgnss.com/site.php
Wikipedia also has a well written article on D-GPS - its interesting to note the availability of a cheap DGPS system usually requires an organization the size of a government - and commercialization in the popular consumer market of this technology is likely difficult with export restrictions in existence (similar to the IMU industry.)
@Alan, @Thomas: last time I looked at an ArduPilot derivative (which was about a year ago) as well as MatrixPilot docs. I am pretty sure the magnetometer heading, like GPS heading, is used to correct for gyro drift. I recall vaguely that the code had provisions for running with or without the compass.
My own experimentation with GPS involves SiRFIII and Venus 638flpx units and in both cases, I got GPS heading data above some low threshold. The Venus, for example, starts reporting reasonably accurate heading above 2m/s. That heading is enough to correct gyro drift. Perhaps the same is true for your GPS.
Both GPS modules reported heading data with a 1 second lag. I compensated for this in my custom autopilot code. I vaguely recall some code in either MatrixPilot or ArduPilot that did some lag compensation but that may have been compass lag, now that I think about it. For rovers making sharp turns, GPS lag must be addressed in some fashion.
Bottom line, compass can help or can hurt, but can be replaced by GPS if either turning is slow and gentle or gps lag is compensated for. Magnetometers can suffer from local -- like, meter by meter -- interference as well as miscalibration etc. That's why I never used one.
Two of the top 3 AVC finishers didn't use a compass -- one (Minuteman) didn't use GPS either, just gyro. The results were quite comparable to the top finisher that was running $1000's worth of industrial grade gyro and gps.
I'm very interested to hear more about the specifics of what is possible specific to ArduRover code. How it uses GPS heading and compass, etc. At some point I'll have to take a peek at the code again as I may port the IMU / DCM stuff to my rover again to do 3d instead of 2d this year. We'll see :)
Hi,
there is a hardware-flow diagram of ardupilot here:
http://diydrones.ning.com/forum/topics/ardupilot-program-flow-diagr...
I'm not sure if it helps further because the rover code is probably revised in the future and Differs from plane code.
but there is an option to print your own diagram with Visual Studio 2012.
you may find information on how to do that here:
http://arduino.cc/forum/index.php?topic=123193.0
Regards,
Linus
Lloyd
thats correct. it is new and because of the porting of ArduCopter, ArduPlane and APMrover for other Hardware i think.
Regards,
Linus
@ Lloyd:
I am using the "ArduPilot-Arduino-1.0.3-windows" IDE and it compiles correctly here.
You have to get the modified Arduino-IDE here:
http://code.google.com/p/ardupilot-mega/downloads/detail?name=ArduP...
select you board from ArduPilot menue and you should be fine.
Regards,
Linus
-
19
-
20
-
21
-
22
-
23
of 30 Next