Originally Posted by Joe Johnson (Post 1313203)

What does the Chief Delphi community think?

Joe J.

Originally Posted by Joe Johnson (Post 1313270)

With regard to moving the robot with power down this happens all the time. But even if it happens only once in a while, do you want to be the team that has its auton mode freak because a field reset requires you to turn your robot off and on.

The problem with using a "know position" at the start is that this is a pretty squishy position in a number of cases. Not accurate enough to reliably shoot frisbees last year (at least for the one robot that I worked with, 3958)

The idea of writing to flash periodically, this solves many problems (especially just a quick power cycle without moving the robot). But it doesn't really solve the move while the robot is off problem.

I THINK that folks are saying this is legal. Is it wise? not sure. Time will tell.

Joe J.

Originally Posted by Joe Johnson (Post 1313270)

The idea of writing to flash periodically, this solves many problems (especially just a quick power cycle without moving the robot). But it doesn't really solve the move while the robot is off problem.

Originally Posted by Alan Anderson (Post 1313274)

Nothing solves the "move while the robot is off problem" if you don't have an absolute position sensor.

Originally Posted by Joe Johnson (Post 1313336)

It is an interesting idea (says the ME who doesn't have to implement the software or the electronics to make it happen!)

Joe J.

Originally Posted by efoote868 (Post 1313618)

If there is a similar rule about batteries integral to COTS parts, it merits asking the GDC if your idea follows the spirit of the rule, since your extra battery is powering more than just the laptop.

Also standard caveat applies - opinions on CD are just that, and they won't hold any weight during an inspection.

Originally Posted by yash101 (Post 1313533)

Do you guys have a suggestion of a low-power MCU to use for the controls? I am currently thinking about using the propeller, but that isn't exactly low-power. It can draw as much as 300mA, running all 8 cogs at max, and all I/O at max threshold!

Originally Posted by yash101 (Post 1313805)

Yeah. I did point out worst-case scenarios, but I think the Prop may draw 100mA at lease, commutating a boost converter. I'd have to set up an entire core to do a PID loop, when the voltage goes lower than 4.9v, pulse the boost converter. When the voltage gets higher than 5.1v, wait for it to drop to 4.9v, then pulse the boost converter. Running this a couple hundred times a second, with a pretty big Capacitor (5,000uF), that should be a good enough speed to give a very stable output of up to, maybe 5 amps!

Originally Posted by techhelpbb (Post 1313818)

You can do that with an operational amplifer as a comparator you do not need an MCU for that. In fact some MCU I have used in power supply systems have integrated voltage comparators.

Originally Posted by yash101 (Post 1313873)

What is an example of a decent MCU with a built-in comparator? Using a comparator will allow me to increase the max current output because the chip will be able to switch faster.

Originally Posted by techhelpbb (Post 1313949)

Microchip and Atmel both offer 8bit MCU with comparators.
Look up the Microchip and Atmel product selectors on their websites it lists all the current production models and you can filter that list to find the ones that fit what you want.



I've gotta ask why you think that lower voltage is going to help you. At this point even the Propeller has a lower drop out voltage than most of the rest of the robot and since this is a FRC targeted idea: why do you need an even lower drop out? If the argument is: but it's another 1V or so I can drop I think you really ought to try to run one of these 2.7-5V chips a bit and see why that's not as great an idea as you think it is. You still need some voltage to drop. At some point you'll still start to brown out and it'll still be be between 3V and 4V DC.



I can't argue that you need 8 cores for what you are doing. There are many things that do not need 1 core (this is one of them). However I can point out to you, actually again, that interrupts are not a wonderful solution to a lot of problems. They create complex situations that are sometimes painfully difficult to digest and can leave you with a problem you can't easily replicate. Stalling development in a fast past environment like FRC where it might have consequences. Should you learn interrupts - yes. Does learning interrupts by necessity make them better than polling or logic: not at all. Somewhere the scientific method should help you deduce which is better for what purpose.



The first is a 32bit version of the Microchips product offering. It's not quite ARM and like the AVR MEGA it's not what most people think of as midrange or low end CPU either.

PIC and PICAXE are both 8bit Microchip PICs.
One has software in it already.

Atmel AVR and the AVR MEGA are 8bit microcontrollers.
Atmel XMEGA offer 16bit.
Atmel AVR U3 offer 32bit (think PIC32 competitor space).

The Parallax Semiconductor (previously Ubicom) chips are 8bit but fast.
I have plenty of old SX chips I don't use because anything that needs that sort of RISC speed I probably move too much data to use those chips.



Whoever told you a design can be perfect needs to look for flaws harder.

If you want to design PCB you may as well start learning how to connect parts because you can not avoid it. It's true that putting some things in the chips can reduce board complexity and the number of layers. However there are many examples of where putting something like an ADC in a chip produces a not so great example of an ADC because you can't alter the ADC to deal with system issues.

I have 2 LPKF PCB mills. I make 2 layer boards all the time. There are many examples where I am assured that I need 4 layers and even in the RF range it works as long as I respect design practice and shield.

PCB designing is a big job and requires a fair degree of knowledge. Do not fear it just learn how to do it because if you make a career out of electronics you'll be doing it again in the future.



You want the flash ISP chips then. You need to get an ISP adapter or make one probably to go from USB to ISP header (and there are different ISP headers).

The Propeller development boards come with the USB to serial adapters.
You'll be in a situation where you don't have that.
ISP is basically serial but usually it's not done these days with a serial port.

There are plenty of cheap Chinese knockoffs of the PIC and AVR ISP programmers that work great.



Best way to get experience is get experience. That said DIP has excellent durability and that's why still today a lot of military electronics are DIP. If you want SMT without soldering find an assembly house.



You are incorrect. I can outrun an MCP3204 with a Propeller but I will do it in assembler.
Now for a better question - what are you doing with that data?



Technically if you want the right tool for the right job you'd remember that you can't just program all the transistors in an MCU. You can't even do that in an FPGA. You can work with the building blocks and interfaces you are offered. In an FPGA those are logic that, if you desired, you could slap together to make a processor like the Propeller (that's how it was prototyped BTW). In an MCU/CPU those blocks are dedicated to functions and the most variability is offered by instructing those functions.

It is an illusion that analog is dead >entirely<. An analog circuit is not subject to illusion of synchronized timing to a clock. True digital has valuable contributions it can make but truly an array of programmable transistor interconnects is an analog construct it does not require a clock even if it can harness it. In fact there was a company that used to make analog programmable circuits.

I often see students trying to bang all problems with the same hammer. Anyone telling you as a student in high school you can't handle analog electronics is being dishonest. I was fixing tube televisions by 7th grade. In the context of your comments previously by the time I was in high school I was programming in assembler on 5 platforms and at least 3 of those professionally for parts of projects (at least one of those was a multimillion dollar job). So whatever reason I could handle that having graduated from high school in 1994 it shouldn't have become harder.



Yes and no. However because the other MCU on your list have proprietary and integrated peripherals you'll have to learn those and their quirks.



I just told you where to find C/C++ for the Propeller as well.



No I wrote what I wrote. An analog mux is a switch usually made from CMOS that functions as a low loss way to connect the internal input of an ADC to another external input of the chip package (in this application). So a chip might say it has 8 analog inputs but it might be 2 single ended ADC with a mux.

If that's the case you can't actually read all the inputs at the same time. You have to switch the mux.



Internal or external ADCs are beasts and the faster they run the more annoying they can be. I worked on oscilloscopes using the XMEGA in Altoids cans that you could put on the robot. 2 channels and all of that internal to the Atmel XMEGA. Cheap yes but with plenty of complications.

Another good part about knowing your external ADC and it being SPI/I2C is you can pivot that knowledge to another MCU. So let's say you decide the Propeller is a way over the top for a production product. So you leave your existing ADC circuit and put it on the other MCU.

That was a big factor in my choice in my helping to propose a 2015 control system. I wanted to know that peripherals were flexible. You could connect them to ARM, Atmel and PIC and connect those all together and the knowledge would transplant (mostly). Building blocks like LEGO instead of a limited COTS product.