Go to Post Remember, however, that such software limitations in no way approximate the functionality of a multiple-speed, mechanical transmission. They're simply a convenient way of limiting your students' lead feet. - Madison [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
 
 
Thread Tools Rate Thread Display Modes
Prev Previous Post   Next Post Next
  #14   Spotlight this post!  
Unread 28-03-2016, 01:32
Jaci's Avatar
Jaci Jaci is offline
Registered User
AKA: Jaci R Brunning
FRC #5333 (Can't C# | OpenRIO)
Team Role: Mentor
 
Join Date: Jan 2015
Rookie Year: 2015
Location: Perth, Western Australia
Posts: 257
Jaci has a reputation beyond reputeJaci has a reputation beyond reputeJaci has a reputation beyond reputeJaci has a reputation beyond reputeJaci has a reputation beyond reputeJaci has a reputation beyond reputeJaci has a reputation beyond reputeJaci has a reputation beyond reputeJaci has a reputation beyond reputeJaci has a reputation beyond reputeJaci has a reputation beyond repute
Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive

Quote:
Originally Posted by artK View Post
This is awesome! Do you have any video of this running on your robot during auto?

My one question is why are you generating these 200 points? Because that seems like a lot. Each spline covers about 2", and you have 199 points where the quintic constraints have you driving straight locally (Since the second derivative is zero when it approaches the waypoint in the spline configuration we developed). I suspect this would make the robot drive a little twitchy, especially when trying to turn.
We don't have a video running auto, in my initial code repo all this was done on a coprocessor (and worked flawlessly on a practice field), however we had some issues with FMS not forwarding ports at the regional I went to, so I turned Motion Profiling off in favor for just a 'go forward for x encoder ticks'.

The reason so many points are generated is because of the nature of the control loop. Each point has a dt value (i.e. how long this control loop iteration lasts before moving onto the next) - in our case, it was 1 / 50. Each iteration (which is timed with the Notifier class from WPIlib) will fetch the next segment and process it.

It is possible to look at the second derivs in order to reduce the amount of points, but that would (at least in the current algorithm) add more time to the actual generation sequence. I can modify the algorithm to correct for this and suffer next to no time overhead. Maybe something to put on my todo list

The path didn't jitter at all, in fact it was very smooth. Turning was very smooth and didn't seem to have any issues
__________________
Jacinta R

Curtin FRC (5333+5663) : Mentor
5333 : Former [Captain | Programmer | Driver], Now Mentor
OpenRIO : Owner

Website | Twitter | Github
jaci.brunning@gmail.com
Reply With Quote
 


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 19:36.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi