Go to Post As my boy Macklemore once said, "The greats weren't great because at birth they could paint, the greats were great because they paint a lot". - Andrew_L [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

 
Closed Thread
Thread Tools Rate Thread Display Modes
  #16   Spotlight this post!  
Unread 22-03-2006, 13:40
ericand's Avatar
ericand ericand is offline
Registered User
AKA: Eric Anderson
FRC #3765 (Terrabots)
Team Role: Mentor
 
Join Date: Jan 2005
Rookie Year: 2004
Location: St. Paul, MN
Posts: 148
ericand is a jewel in the roughericand is a jewel in the roughericand is a jewel in the rough
Re: Offboard coprocessor!

Quote:
Originally Posted by Doug G
We do the same thing with our shooter, but just simply use a couple of encoders connected to the RC and Watson's velocity PID code with some tweaking of the constants and are getting pretty good results. So why use the separate PIC?
2 reasons to use the PIC

1) The student who did it had some PIC experience and wanted to add a bit of interesting control circuitry. This also provides an example for future robots.

2) We were worried about the interrupt overhead from the impellers spinning at over 2000rpm. We did do a pass through mode so that (if there was a problem with the sensor PIC) we could hook the sensors up to interrupts 5 and 6 and do everything in the RC.

The off board PIC can determine the speed on every revolution by measuring the pulse width. The sensor
sees one high and one low every revolution.

We also thought about routing the GTS signals (from our robot drive system) through the PIC (or a similar device) to get the drive rotational direction since measuring the GTS pulse width is difficult to do in the RC. However, we ran out of time to do that.
  #17   Spotlight this post!  
Unread 22-03-2006, 18:07
devicenull devicenull is offline
Robot? We need a robot?
no team
 
Join Date: Sep 2004
Rookie Year: 1234
Location: n/a
Posts: 359
devicenull is just really nicedevicenull is just really nicedevicenull is just really nicedevicenull is just really nicedevicenull is just really nice
Re: Offboard coprocessor!

Quote:
Originally Posted by Gdeaver
I'm curious as to why there is a need for a powerful coprocessor. I can see using a small PIC for a sensor that requires I2Cc or SPI interface since we don't have access to the hardware on the robot controller. This year the camera certainly didn't overwhelm the processor. There are more limitations in the actual camera hardware and firmware. So why the need for a powerful
coproc? Are our games complex enough to justify one?
If your going to go through the effort of adding one, why not make it forwards-compatible? Sure, you might not need 400mhz of computing speed now, but what about in two years.. Wouldn't it then be a waste to have to redevelop everything?
  #18   Spotlight this post!  
Unread 22-03-2006, 18:45
lupjohn's Avatar
lupjohn lupjohn is offline
Registered User
AKA: Larry Upjohn
FRC #0692 (FemBots)
Team Role: Mentor
 
Join Date: Oct 2004
Rookie Year: 2002
Location: Sacramento, CA
Posts: 31
lupjohn is an unknown quantity at this point
Re: Offboard coprocessor!

Quote:
Originally Posted by Doug G
We do the same thing with our shooter, but just simply use a couple of encoders connected to the RC and Watson's velocity PID code with some tweaking of the constants and are getting pretty good results. So why use the separate PIC?
If you use the camera you are using a peripheral controller. In the 80S there was one controller chip in your car. Now, in the next century, I am sure there are at least 6 or more through out the new cars that communicate using the CAN networking protocol. My team has not utilized all of its computing power yet but ideally this would have been the way to go. Such as to off load some of the computational load for the shooter/camera combo to keep the master RC reasonably stressed. It is complex from the software standpoint particularly if you have several development environments ( IDE's, compilers, assemblers, etc.) to work with but the robot may be more effectively controlled by breaking down the control tasks and distributing the workload to peripherals closer to the effected component. Someday. LRU.
  #19   Spotlight this post!  
Unread 25-03-2006, 11:04
lukevanoort lukevanoort is offline
in between teams
AKA: Luke Van Oort
no team
 
Join Date: Oct 2005
Rookie Year: 2005
Location: Waterloo, ON, Canada
Posts: 1,873
lukevanoort has a reputation beyond reputelukevanoort has a reputation beyond reputelukevanoort has a reputation beyond reputelukevanoort has a reputation beyond reputelukevanoort has a reputation beyond reputelukevanoort has a reputation beyond reputelukevanoort has a reputation beyond reputelukevanoort has a reputation beyond reputelukevanoort has a reputation beyond reputelukevanoort has a reputation beyond reputelukevanoort has a reputation beyond repute
Send a message via AIM to lukevanoort
Re: Offboard coprocessor!

Quote:
Originally Posted by Gdeaver
I'm curious as to why there is a need for a powerful coprocessor. I can see using a small PIC for a sensor that requires I2Cc or SPI interface since we don't have access to the hardware on the robot controller. This year the camera certainly didn't overwhelm the processor. There are more limitations in the actual camera hardware and firmware. So why the need for a powerful
coproc? Are our games complex enough to justify one?
Omni style drive systems can be. Also this year, if you threw PID loops on shooters and drivetrain, exponential joystick smoothing, pots on turret elevation and rotation, light sensors for ball indexing, accelerometers for traction control and auto, camera running a turret constantly, had a killough omni drive, and tried to run it all really fast without using any look-up tables, you might run out of power. (Or have to slow down response times) Hence, the offboard processor. In fact, if you learned to use it in the offseason, the offboard processor might speed up your programming, by letting you do quick and dirty solutions instead of having to optimize.
__________________
Team 1219: 2009 - Mentor
Team 587: 2005 - Animator, 2006-2008 - Team Captain
  #20   Spotlight this post!  
Unread 28-03-2006, 18:34
mogunus mogunus is offline
Registered User
AKA: Luciano DiFalcone
FRC #1350 (Rambots)
Team Role: Programmer
 
Join Date: Jan 2006
Rookie Year: 2003
Location: RI
Posts: 19
mogunus is an unknown quantity at this point
Re: Offboard coprocessor!

I use an offboard coprocessor for ease of programming and added horsepower. The PIC18 C is really too troublesome to write stereoscopic vision routines in, never mind powerful enough to execute them. For Manchester regional, what I got working was a really simple trig-based binocular vision scheme, a complete and total hack using two cameras, the light, and a gumstix. The reason I could use such a trig-heavy approach was the gumstix, you need lookup tables for that on a PIC, and using the actual functions would really slow you down.

For nationals, I'm working on implementing true binocular vision on the gumstix/cmucam array, along with the "light hack" for easy aiming. I might end up adding a third cmucam, I'm not sure. But this opens up all sorts of fun possibilities... In auto, stereoscopic vision combined with a good positioning system can lock on to, track, and ram an enemy bot. When I'm done and it doesn't look stupid anymore, I'll post the code for that.

(Also, the gumstix runs linux. Linux programming environment = wonderful. You can only program a PIC using clunky wine wrapperthings in linux. This way, there's the one PIC code that works and then you're done messing with that, its just easier to work with two linux systems and two REAL implementations of gcc, not PIC18 special C)
__________________
... one of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs.
-- Robert Firth
Closed Thread


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 03:38.

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