Robotic Path Planning In 2D, How Simple or Complicated Can It Get? / Computer Science / Forums

Forums

4hv.org :: Forums :: Computer Science

« Previous topic | Next topic »

Robotic Path Planning In 2D, How Simple or Complicated Can It Get?

previous 1 2 3

Move Thread

LAN_403

Dr. Slack

Mon Aug 12 2013, 05:30AM

Registered Member #72 Joined: Thu Feb 09 2006, 08:29AM
Location: UK St. Albans
Posts: 1659

Patrick wrote ...

... but am I creating a mesh in x and y like a grid, or as a polar system? the lidar is polar, but the navigation doesn't have to be one or the other.

That's the beauty of the system, the coordinates can be in any system you like. Navigation will always avoid crashing, though a path of true least cost requires that the model costs represent the true real world costs. So if you implemented a log-polar model with uniform resistors, you would find that the chosen path always avoided the origin. Angle cosines work well for robot arms.

Polar lidar results are probably too low level to be using directly in a higher level planning tool like this. I agree with Steve's layered approach. When you develop, you will want to work on very low level, or higher level seperately, and will need a well thought out API to be able to swap modules in and out. The natural coordinate system for the higher level map data will be cartesian, whatever the robot eyes see in.

Ash Small

Mon Aug 12 2013, 12:53PM

Registered Member #3414 Joined: Sun Nov 14 2010, 05:05PM
Location: UK
Posts: 4245

The robot arm and the 'copter are fundamentally different in one respect.

The robot arm is controlled by hydraulics/steppers and can 'freeze' while a decision is made.

The 'copter' can't 'freeze', it is 'dynamic' all the time.

As Steve has explained, any form of AI should have 'self preservation' as it's priority (subject to the 'Three Laws', of course). Mapping surroundings should be second order priority, and the 'Mission' should be third order priority, in my opinion.

Patrick

Mon Aug 12 2013, 04:46PM

Registered Member #2431 Joined: Tue Oct 13 2009, 09:47PM
Location: Chico, CA. USA
Posts: 5639

Steve, im still thinking on the memory problem.

as for the lidar, ill convert it to Cartesian, and the navigation grid too. Ill have immeadiate interrupts for self preservation if some minimum distance is violated.

im not sure how to code blocks of functions and then have them run as needed though, and yet still keep the PID flight controller up and given the highest priority. im looking through my book now. im not as good at this coding bit as you guys, im mostly a fabrication and electrical guy...

Steve Conner

Mon Aug 12 2013, 07:08PM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

Interrupts are your friends in this kind of situation. Typically you would set up a timer interrupt to run the flight controller tens of times per second as an interrupt service routine (ISR). Whenever the interrupt fires, the processor puts its current task to one side, executes the ISR, then resumes the original task where it left off.

Matters often come unstuck when trying to communicate between the ISR and the rest of the program. It is all too easy to bodge up some ad-hoc system of flags and variables that seems to work but actually has a hidden race condition. (I believe most of Windows 3.1 through to ME was written like this

) For all but the simplest communication tasks, you should use synchronisation objects like critical sections and semaphores, and then you have to watch out for deadlock.

My favourite method nowadays is a STL queue protected by critical sections. The critical sections protect the queue from race conditions (needed as the STL is not thread safe) and the queue protects the critical sections from deadlock (operations on a queue never block) so it "just works".

Ash Small

Mon Aug 12 2013, 07:41PM

Registered Member #3414 Joined: Sun Nov 14 2010, 05:05PM
Location: UK
Posts: 4245

Steve Conner wrote ...

Interrupts are your friends in this kind of situation. Typically you would set up a timer interrupt to run the flight controller tens of times per second as an interrupt service routine (ISR). Whenever the interrupt fires, the processor puts its current task to one side, executes the ISR, then resumes the original task where it left off.

This is exactly what I'd do.

Patrick

Tue Aug 13 2013, 11:34PM

Registered Member #2431 Joined: Tue Oct 13 2009, 09:47PM
Location: Chico, CA. USA
Posts: 5639

im looking up all my old homework on ISRs for the STM32/ arm cortex stuff now.

Patrick

Thu Aug 15 2013, 02:53AM

Registered Member #2431 Joined: Tue Oct 13 2009, 09:47PM
Location: Chico, CA. USA
Posts: 5639

im laying up carbon and glass composite right now. im putting together a more capable tri-copter, just for path planning demonstration. it will have a 2 kg lift capability and the ability to fly through human doorways and halls.

im not abandoning my bi-copter, but that tech isn't capable or mature enough yet.

BigBad

Fri Nov 29 2013, 05:11PM

Registered Member #2529 Joined: Thu Dec 10 2009, 02:43AM
Location:
Posts: 600

For shortest path calculation, the Dijkstra algorithm runs quickly and is simple and can deal with loops.

Shrad

Fri Nov 29 2013, 05:42PM

Registered Member #3215 Joined: Sun Sept 19 2010, 08:42PM
Location:
Posts: 780

there are game path finding algorithms available in python or other simple languages which would be able to run on such systems as STM32

previous 1 2 3

Moderator(s): Chris Russell, Noelle, Alex, Tesladownunder, Dave Marshall, Dave Billington, Bjørn, Steve Conner, Wolfram, Kizmo, Mads Barnkob