Go to Post Being involved with FIRST is a privilege, not a right. - Katie Reynolds [more]
Home
Go Back   Chief Delphi > Technical > Electrical
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
  #91   Spotlight this post!  
Unread 05-11-2013, 00:18
yash101 yash101 is offline
Curiosity | I have too much of it!
AKA: null
no team
 
Join Date: Oct 2012
Rookie Year: 2012
Location: devnull
Posts: 1,191
yash101 is an unknown quantity at this point
Lightbulb Re: Driver station power

Microcontrollers are quite fun to work with. They allow me to do rapid prototyping without messing too much with the electrical components. I will probably have an MCU controlling this driver station. What do you guys think about the Parallax Propeller (P8X32A)?
  #92   Spotlight this post!  
Unread 06-11-2013, 19:36
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,624
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Driver station power

Quote:
Originally Posted by yash101 View Post
Microcontrollers are quite fun to work with. They allow me to do rapid prototyping without messing too much with the electrical components. I will probably have an MCU controlling this driver station. What do you guys think about the Parallax Propeller (P8X32A)?
I think it's quite nifty.
Nifty enough I offered to build FIRST a control system based on it.

Just wait till you see the second generation.
  #93   Spotlight this post!  
Unread 06-11-2013, 20:49
yash101 yash101 is offline
Curiosity | I have too much of it!
AKA: null
no team
 
Join Date: Oct 2012
Rookie Year: 2012
Location: devnull
Posts: 1,191
yash101 is an unknown quantity at this point
Talking Re: Driver station power

Yep. Just can't wait! The 2015 Control System seems great. What do you guys think? Also, if we were to use Propeller Chips, the supply of them would get overwhelmed! However, most teams would only need one because of how robust they are. Mine has gone through electrostatic discharge, I/O shorted out and lots of other bad things. Yet, the chip works like a charm. This would only give Parallax a reason to grow larger, thus reducing their product prices!
  #94   Spotlight this post!  
Unread 07-11-2013, 01:46
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,624
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Driver station power

Quote:
Originally Posted by yash101 View Post
Yep. Just can't wait! The 2015 Control System seems great. What do you guys think? Also, if we were to use Propeller Chips, the supply of them would get overwhelmed! However, most teams would only need one because of how robust they are. Mine has gone through electrostatic discharge, I/O shorted out and lots of other bad things. Yet, the chip works like a charm. This would only give Parallax a reason to grow larger, thus reducing their product prices!
I meant the second generation Propeller.
Parallax has more than sufficient production for the first generation for everyone in FIRST to buy several.
I checked when I answered to RFQ.
  #95   Spotlight this post!  
Unread 07-11-2013, 08:19
yash101 yash101 is offline
Curiosity | I have too much of it!
AKA: null
no team
 
Join Date: Oct 2012
Rookie Year: 2012
Location: devnull
Posts: 1,191
yash101 is an unknown quantity at this point
Lightbulb Re: Driver station power

Yes. However, Parallax is still a small company and there are many product manufacturers who use their products.
If demand increases and the supply remains constant, there is a shortage and the price goes up.
If the demand decreases and the supply remains constant, there is an abundance and the price goes down
If the demand remains unchanged and the supply increases, the price goes down. Ceteris Paribus.

Some economics review for me. I think it is the supply-demand curve which would give us the price after heavy load. Also, after the kickoff, many teams won't need another for a while, creating an abundance and reducing the price.
We could expect to pay $11 per chip instead of 12!
  #96   Spotlight this post!  
Unread 07-11-2013, 09:29
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,624
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Driver station power

Quote:
Originally Posted by yash101 View Post
Yes. However, Parallax is still a small company and there are many product manufacturers who use their products.
If demand increases and the supply remains constant, there is a shortage and the price goes up.
If the demand decreases and the supply remains constant, there is an abundance and the price goes down
If the demand remains unchanged and the supply increases, the price goes down. Ceteris Paribus.

Some economics review for me. I think it is the supply-demand curve which would give us the price after heavy load. Also, after the kickoff, many teams won't need another for a while, creating an abundance and reducing the price.
We could expect to pay $11 per chip instead of 12!
Parallax has ample production to handle this load.
The cost of the Propeller is so low compared to 8 PICs or 8 AVR plus the support circuitry I wouldn't worry about it.

The key trade off with the first generation Propeller is the lack of peripherals.
It is also in some ways a positive.
You don't get stuck with whatever the chip designer may have goofed.
However you don't get the benefit of cheap integrated peripherals when you buy the MCU.

In reality Parallax has been able to support putting production volume in Radio Shack, schools, some business ventures to the point of product starting to hit surplus stores and they have past experience with FIRST in the sense that the control system circa 1997 and 1998 was essentially 2 Parallax BASIC Stamp 2 on the robot side. One BASIC Stamp 2 was tasked with the field radio tasks and the other was open to the students to do as they pleased.

In effect a single Parallax Propeller in an FRC style control system is 4 times the power and because of the way the I/O round robins it is vastly more flexible (at the small price of some enforced timing requirements that are...for this application...quite workable).

The answer to the FRC control system bid U.S. Cybernetical made would have allowed a cooperative system of one or more Parallax Propellers onto the robot. Literally to the point that you ran out of electricity. It would have been possible to literally assign cores (cogs) to functions even almost whole Propellers. Plus you could have used the Propellers on the driver's station.

When last I worked on this I had the ability to issue orders to whole subsystems in near plain English. Literally telling a prototype to: move left wheel forward at 20 RPM. Of course that was one concept.

I also have a graphical language I started creating to open source (effectively an alternative to LabView) that targets the FRC style system I laid out. However given the lack of interest from FIRST I am withholding that software until I feel it is in my interest to release it (my work, my choice).

In any event the big downsides from the Propeller are:

Lack of floating point math (has to be transparently emulated or done in a co-processor...both of which I did)
Lack of a hardware multiply (no longer an issue in the second generation Propeller)
Lack of hardware interrupts (depends on how deadset you are on hardware interrupts as they have upsides and downsides)
Lack of on-board integrated peripherals (they do have lookups for trig functions, PLL, etc)
Lack of a defacto real time operating system (in reality real time OS are often misunderstood and overhyped)
Lack of hardware drivers for say cameras (this is not as big a deal as it seems)

None of these would have prevented creating near supercomputing performance control system on an FRC robot.
The cameras could have integrated ARM processors, use a laptop, or stream to the driver's station.

One concern FIRST stated was that they felt it was too complicated for the students to understand.
Well...in truth...I find that doubtful considering the rules for FRC are pretty darn vast and complicated.

Oh and the control system with the radio was around the $300 mark when I last looked with a single Parallax Propeller at the stated retail price currently and a Turtle low frequency radio for the field communications sporting an additional Atmel AVR or Microchip PIC (locked out for FIRST's control). From there the additional ready to assemble Parallax Propeller modules were much less than $75. So really for the cost of the original cRIO you could have dozens of Parallax Propeller on a single robot. With multiple or single sidecars (the I/O to the side cards was flexible so you could redirect sidecar peripherals to one or several Parallax Propeller like a baseband network).

I didn't leave ARM out either. I made a camera module with an ARM CPU. However my design choice was that if real time OS was your ultimate demand put a laptop on the robot and plug the Parallax Propellers into that laptop. Use the highly cost effective laptop as your slave peripheral like people do now with things like the Beagleboard. The interrupt driven nature of the laptop on the robot could be easily over come into the real time domain using the Parallax Propeller to enforce timed operations where the laptop would otherwise have issues (such as monitoring an A/D converter, reading encoders...etc).

Last edited by techhelpbb : 07-11-2013 at 09:49.
  #97   Spotlight this post!  
Unread 07-11-2013, 09:38
yash101 yash101 is offline
Curiosity | I have too much of it!
AKA: null
no team
 
Join Date: Oct 2012
Rookie Year: 2012
Location: devnull
Posts: 1,191
yash101 is an unknown quantity at this point
Talking Re: Driver station power

Looking at the specifications of the propeller ii, it seems though the processor is oowerful enough for vision. Also, I believe they are adding a lot of ADCs and DACs. It will then be an entire computer
  #98   Spotlight this post!  
Unread 07-11-2013, 09:57
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,624
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Driver station power

Quote:
Originally Posted by yash101 View Post
Looking at the specifications of the propeller ii, it seems though the processor is oowerful enough for vision. Also, I believe they are adding a lot of ADCs and DACs. It will then be an entire computer
Parallax has made several alternations to the Propeller II design the last few years. The Propeller I is already powerful enough to play an 80s classic video game and generate the 4MHz NTSC video signal with some cheap extra parts. It doesn't have a true ADC/DAC per se. It cheats using a trick similar to the BASIC Stamps.

The trick with using the Parallax Propeller (current or otherwise) for vision is to understand how to divide the tasks of the vision system into parallal operations to take advantage of the hub memory and extra cores (cogs). This is itself much more tricky then just getting OpenCV and slapping it on laptop. On Team 11 we've written vision software from the camera driver up but in 6 weeks that's a challenge. Also you start to get into calculus, linear algebra and several other mathematic fields that normally high school students are not yet all that familiar with.

Honestly the best way to overcome vision on the Propeller itself would be to get someone to 'own' the project and let them develop the extensive library of tools you really want to offer it as a 'plug and play' option.

It's possible even with the Propeller I but it's a lot of subtle work and people would be right to ask why do that work when there are other ways already cost effective to achieve the same result.

Other than the camera really the Parallax Propeller is an SVGA, keyboard and mouse capable computer already.
See DEFCON for a fine example:
http://dangerousprototypes.com/2012/...lax-propeller/

All you had to do was solder on the HD-DB15, a PS2 keyboard and PS2 mouse connector and you have a 'PC'.
As you walked around they even talked to each other (it was part of the fun...you needed the rest of the badges to solve the puzzle).

Last edited by techhelpbb : 07-11-2013 at 10:19.
  #99   Spotlight this post!  
Unread 07-11-2013, 10:49
yash101 yash101 is offline
Curiosity | I have too much of it!
AKA: null
no team
 
Join Date: Oct 2012
Rookie Year: 2012
Location: devnull
Posts: 1,191
yash101 is an unknown quantity at this point
Talking Re: Driver station power

I guess.
Anyways, here is the feature list. Pretty Impressive with the 1200 MIPS!
http://www.parallaxsemiconductor.com...ropeller2specs
  #100   Spotlight this post!  
Unread 20-11-2013, 22:10
yash101 yash101 is offline
Curiosity | I have too much of it!
AKA: null
no team
 
Join Date: Oct 2012
Rookie Year: 2012
Location: devnull
Posts: 1,191
yash101 is an unknown quantity at this point
Wink Re: Driver station power

So, I have been tinkering with the CAD of this cart. What drivetrain would be best?

Manual:
Castor
Cart
Something Else (Please comment it)

Motorized:
Swerve
Cart
Mecanum
Other Holonimic (Omni, etc.)
Locking Mecanum
Legged (Seems quite impractical!)
Something else (please comment it)

Also, for control, what should I use?
Gaming joystick
xBox/vex type joystick
Arrow keys on computer
Buttons
Pressure sensors
Brainwave
Eye tracking
Mouse
Spring-loaded potentiometers
Pot Handlebars
Levers (Hand)
Levers (Foot)
Autonomous (Quite impractical)
Something Else (Please Comment it)

Also, what do you guys think of the idea that the driver station docks onto this battery cart? Do you guys like it, want me to trump it or want more info about it?
  #101   Spotlight this post!  
Unread 20-11-2013, 22:17
yash101 yash101 is offline
Curiosity | I have too much of it!
AKA: null
no team
 
Join Date: Oct 2012
Rookie Year: 2012
Location: devnull
Posts: 1,191
yash101 is an unknown quantity at this point
Lightbulb Re: Driver station power

BTW, for the propeller, I came up with a nifty idea:
To write a Java interpreter, compiler and kernel to be installed to the propeller. This kernel would fetch instructions from an SD card, parts at a time, allowing a large code. Also, the compiler would convert the code to bytecode to run efficiently on the propeller. I am pretty sure that a 128 MB card will be enough to hold Google's Search Engine Code (Not their database or their other services).

I think there are some practical uses for something like this, as it would allow you to access the inaccessible features on the Propeller!

Also, how can I add more RAM for variable space on the propeller? I would like all the user variables to be in an external RAM of 16Mbit, meaning that they do not need to worry about RAM.

The only thing this may not be able to do is image processing (Or maybe it can).
  #102   Spotlight this post!  
Unread 20-11-2013, 23:25
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,624
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Driver station power

Quote:
Originally Posted by yash101 View Post
BTW, for the propeller, I came up with a nifty idea:
To write a Java interpreter, compiler and kernel to be installed to the propeller. This kernel would fetch instructions from an SD card, parts at a time, allowing a large code. Also, the compiler would convert the code to bytecode to run efficiently on the propeller. I am pretty sure that a 128 MB card will be enough to hold Google's Search Engine Code (Not their database or their other services).

I think there are some practical uses for something like this, as it would allow you to access the inaccessible features on the Propeller!

Also, how can I add more RAM for variable space on the propeller? I would like all the user variables to be in an external RAM of 16Mbit, meaning that they do not need to worry about RAM.

The only thing this may not be able to do is image processing (Or maybe it can).
Let's break this idea into smaller parts.

There is already a stub you can put into a Propeller Cog that will load program and variables from the Hub memory. At the cost of waiting for the round-robin Hub mechanism.

One could load the Hub memory via Cog(s) to contain segments of code and variables interchanged from some of the remaining Cogs then sent back and forth to external memory or devices.

The price you pay for this from the perspective of any single otherwise unassigned Cog is waiting for the Hub mechanism to move data into the shared memory. Waiting for the Hub mechanism to give access to the Cogs that transact the data with the external devices. However let us not underestimate that the greatest delay will be to get the data into and out of the I/O pins on the Propeller to whatever else is out there.

This is no different than the way I created a control system as a network of interconnected Propellers. The greatest delay is at the I/O to the other chips (other Propellers, memory, sidecars...whatever they might be). You can cheat some. You can use more than 1 bit at a time. Making a parallel communications bus. You can make the transactions synchronous eliminating slow asynchronous timing issues. If you do this right you can pump data fast...but still not as fast as what you can do inside the Propeller itself.

The point: ideally you want to avoid moving data external to the Propeller for any purpose where speed is critical. In those cases you are far better off say: consuming 7 Cogs for a purpose, confining the process to those Cogs and then using the left over Cog to spew less critical communications to the rest of the system.

It would be ideal if there was a massive amount of Hub shared memory. Then again that is static memory. Most PCs use dynamic memory which is effectively slower and more tricky because large quantities of static RAM would get expensive. I hesitate to say just what the perfect balance here is. Even x86 CPU pay dearly in performance when they reach outside to access the system RAM. That's why the CPU cache is so important. So think of the shared Hub memory as a shared CPU cache. As most modern CPU are actually running a program you can't alter called microcode there's further similarity there to be explored. The loss created by the external I/O does come at a price but it's a price common to other computing designs as well. The massive difference in favor of the Propeller is that you can control aspects of the cost for the external access (add more bits to the bus, compress data, change the segmentation, alter the timing) something there are very real limits on in other architectures as they are more general purpose oriented (you can be great at one thing or mediocre at lots of things).

Last edited by techhelpbb : 20-11-2013 at 23:44.
  #103   Spotlight this post!  
Unread 21-11-2013, 13:04
yash101 yash101 is offline
Curiosity | I have too much of it!
AKA: null
no team
 
Join Date: Oct 2012
Rookie Year: 2012
Location: devnull
Posts: 1,191
yash101 is an unknown quantity at this point
Lightbulb Re: Driver station power

So, could I add a memory buffer method to create a variable in the Built-in RAM, and use that for high speed access? That way, the variable is copied into the internal RAM. The hub can then access the ram quickly
  #104   Spotlight this post!  
Unread 21-11-2013, 13:31
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,624
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Driver station power

Quote:
Originally Posted by yash101 View Post
So, could I add a memory buffer method to create a variable in the Built-in RAM, and use that for high speed access? That way, the variable is copied into the internal RAM. The hub can then access the ram quickly
I think this might be beneficial to read:
http://propeller.wikispaces.com/Large+Memory+Model
That assembly code not just copies data from the Hub RAM, that data is actually executable code.
Just data is by comparison pretty simple.

Basically you want to move the private performance critical variables into the internal Cog RAM (not to be confused with internal to the Propeller chip) for the highest speed.

Public performance critical variables within a Cog need to get that Cog to 'export' them into the Hub shared RAM and anything in the Hub shared RAM needs to get a Cog to import it.

The difference between private and public here is important and differs slightly from the way those terms are often used, so I will explain:

A private variable rarely needs to be exposed to the Hub at all so it gets maximum performance.
A public variable is probably being often exchanged with the Hub.
(Who decided on the names public and private in this context? I just did it's part of some code I already wrote.)
To make things easy to see you should group your private variables together within the Cog. The same with the public variables.
Then you can code an 'export' function to periodically take the public variables that are grouped together and move it as a segment sequentially into the Hub (if you think about this these grouped variables are effectively what assembler programmers refer to as a stack so you have multiple stacks being copied as segment to the Hub shared memory at time intervals dictated either by a timer or loop execution).
One might need to have some of the public segment more frequently update than others so if that is desired group the public variables together based on update frequency. The key is to keep the variables together to keep the operations sequential (making the loops simple increments).

This is a software imposed version of memory management for the < 500 longs of memory within each Cog. You pay for it in the performance of each Cog the instant you make anything public (because something has to steal Cog processing time to move the data). However once you design the system you can clone it over and over for each Cog.
This sounds complicated but even in straight assembler it is short.

The highest performance can be demanded from a Cog that never interacts with the Hub round-robin mechanism.
The more the Cog interacts with the Hub the more performance you loose to that interaction.
So if you are setting aside time to move 20 longs to the Hub shared memory: what I described can be done really fast at each opportunity without missing any opportunity, or setup interleaved into other timing critical operations and still be understandable if you need to debug it.

Last edited by techhelpbb : 21-11-2013 at 13:48.
  #105   Spotlight this post!  
Unread 22-11-2013, 15:49
yash101 yash101 is offline
Curiosity | I have too much of it!
AKA: null
no team
 
Join Date: Oct 2012
Rookie Year: 2012
Location: devnull
Posts: 1,191
yash101 is an unknown quantity at this point
Re: Driver station power

That makes sense because the hub is the bottleneck! The hub isn't too fast and is serving so many cogs that there are very few times where the hub will be able to be used well! That's like my computer, where the hard drive (SSD) gets a seven, but the processor gets a three, causing my computer to be veerry slow!

Last edited by yash101 : 22-11-2013 at 15:51.
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 13:55.

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