46380Re: [SeattleRobotics] Re: Accurate odometry
- Jan 2, 2012Hi Peter,
Delphi? Been a while since I heard that name! As I recall it's similar
to Pascal. I played a little with UCSB Pascal (8" floppy), but after I
learned C on UNIX, I didn't do much with it. There is a CNC controller
program with source available, TurboCNC, which causes me to read Pascal
once and a while, but that's about it. C works for my needs.
When exactly does DPA switch back and forth from wall following? When
encountering an obstacle? There must be some sort of comparison between
target vector strength and obstacle vector strength? Or maybe after the
target is "in the clear" from the obstacle. That will take a bit more
thought. Interesting problem!
Surly there are modules that you can re-use! When I was doing my CNC
controller program, I already had a text-based GUI (TUI?), and I used it
for many programs. About all the simulation I ever did was to draw the
tool path on a grid in the controller program.
On 1/2/2012 2:13 AM, Peter Balch wrote:
> From: KM6VV
>> Interesting simulation!
> Please do try your own algorithms.
> I still don't feel I understand why dpa's version doesn't sideswipe trees
> while mine does. I don't really believe his PID limits angular acceleration
> as much I had to.
> As Randy says, a PID achieves fastest possible closure between target
> setting and actual output. I'm sure that jBot has a faster angular
> acceleration than 0.5 rad/sec/sec.
> Plus, I ought to try dpa's algorithms for switching to/from wall following.
>> You must have a "simulation engine" or similar to write all your
>> simulations. C language, I presume?
> A "simulation engine"? I wish.
> I write them all from scratch in Delphi. I'm one of those weirdos who
> believes they can write better, faster, more reliable code, more quickly in
> Delphi than in C/C++/Java. I've managed to make a few other converts but it
> does have it's disadvantages to be the only person marching in step. Sigh.
> It would be nice to have a "simulation engine" but they're all sufficiently
> different that it's always easier to start again. Yet they're all
> sufficiently similar that I find myself writing the same code over and over.
> In the case of Buggy.exe, I ought to have used the nicer
> compiler/interpreter I have squirrelled away somewhere but I couldn't find
> it and, once again, wrote one from scratch.
- << Previous post in topic Next post in topic >>