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
Wouldn't the gyros and accelerometers be used for inertial navigation and correction for the magnetic compass?
My APM2 just arrived, and it looks like I can move the compass and GPS (already separate) up a pole to keep them away from the magnetics and noise of the motors. Yeah, a few things we don't need on the APM2. like the altitude (barometric pressure sensor!
I was hoping to use my Razor 9DOF IMU, but I'm not ready to rewrite the code either!
I just noticed the Sonars used, and they're not the SRF08 units (6) I was going to use. I really want to run my sonars by a separate uP (Schmartboard, $15), and send an "obstacle quadrant" message to the uP running navigation above the APM2. Same for the LiDAR module I hope to use. Although it sends about 768 samples for each pass.
My thinking is that Sonar, LiDAR, IR and the APM2 should all send their bearing and speed info in a similar format, and the upper-level navigator would then either weight them, or use behaviors to sort them out. So having similar-context sensor information might make the task of sensor fusion easier.
The APM2 reads the sonar, how much obstacle avoidance does it do?
I think it was said that differential steering (tank) could be done by selecting "Aileron mixing". Not as important if we use a supervisory uP. The forward/reverse is handled by the value (< 1000mS or > 1000mS) pulse width of the Throttle PWM, if I'm not mistaken.
Alan
@Thomas
Going for APM1 seems feels like a bit of a backward step and I don't think there's much of a price difference. However, the robot is only intended for a top speed of about 5 miles/hr so that probable leaves the gyro and acclerometer redundant. What I do like about the ArduRover though is the mission planner and connecting it with 3DR radios and being able to control it from a PC.
@Niall,
I am presently just using the APM1 with GPS and compass and no Oilpan. You can add a sonar/IR sensor to the APM1 as has been documented in the ArduRover wiki. The only advantage to having an APM/Oilpan or APM2 is that you could use the gyro and accelerometer to help stabilize the rover in fast turns. However, you can slow the rover down during turns and speed up after the turn without having to have a gyro or acclerometer.
Just a thought.
Regards,
TCIII
I'm still undecided about buying an APM2 for my robot. My main concern is that a lot of the sensors and code seem to be redundant for the purpose of using it in a ground vehicle but maybe someone could correct me if I'm wrong about this. Also, I need PWM signals for tank steering and 2 High/Low outputs for forward and reverse and I dont fancy messing about with the code too much.
Anyone any thoughts or suggestions?
@Thomas,
Yeah, that's about what I was thinking. However, you'll still want obstacle avoidance working before arriving at the waypoint (circle). Once in the waypoint circle, we have the problem of finding the target cone. Problem might be if there were also obstacles in the area.
Regards,
Alan
@Alan,
Once the rover has reached a waypoint, the APM1 could generate a digital output that the avoidance process would respond to by going into a visual recognition search mode to identify and get close to the way point target. In the mean time the APM1 would be giving steering commands to the next waypoint which the avoidance processor would ignore until it had completed target recognition and closure. After that the avoidance processor would go into the waypoint navigation mode while avoiding obstacles until it received another waypoint arrival digital indication. Comments?
Regards,
TCIII
@Thomas,
Oh, that's the getRadio and getRadioScaled routines. So we basically pretend we're being commanded by an R/C radio. Works!
I did see quite a few little programs to demonstrate the Mind's eye peripherals.
I've got code from my Table Top 'bot, I did some subsumption routines in it, like don't fall off the table! I did two levels of target seeking (IR), so that should be useful. I've previously written Sonar avoidance routines. Probably similar.
Do you know if we can query the APM2 for other bits of info? Or have the APM2 send out messages, like "within waypoint circle", which could be used to alert the supervisor module that it's time to change behavior to that of seeking rather then avoiding an object? I suspect there must be some sort of signal that one was approaching a waypoint. I'd like to slow down and then start looking around. For a waypoint with a cone, one would want to touch it. For just a "course" waypoint (point where the 'bot would change to a new bearing?) then just the bearing change would be desired.
Is there a paper that describes all the neat stuff that the APM2 can/will do?
Regards,
Alan
@Alan,
The Arduino Uno PWM conversion code is in the Minds-i Library file that can be found here:
http://www.mymindsi.com/code
Regards,
TCIII
@Thomas,
That's probably fine, after all, it's not a position we're seeking, it's just an error to be used to control a servo's rate. I think the SSC-32 resolves down to 1uS, but that accuracy may not be important here.
Is this code available somewhere?
Regards,
Alan
x-SSBN622
@Alan,
The Arduino Uno obstacle advoidance program uses a subroutine to decode the PWM inputs. The subroutine scales the 1.0ms to 2.0ms PWM to a range of 0 to 180 with 90 being the center at 1.5ms. Repeatability of the measurement when I moved the steering and throttle controls was very consistent. If you divide 2ms by 180 you will get the resolution of the conversion which should be around 11us.
Regards,
TCIII