How would I interface a flash drive to the RC?

[EHaskins]

look at these
http://www.sparkfun.com/commerce/pro...oducts_id=7955
http://chipdos.com/

hope this helps

[Matt Krass]

An offboard PIC or AVR with an attached dataflash module could easily do it, AVRs can be entirely self-contained so all you'd need is a serial connector, the AVR and the flash memory, I'm not sure if you can draw enough power right off the serial port, but you should be able to draw from a few PWMs to power it, it'd be a nice project, AVRs can be programmed in assembly, C, BASIC and a few other languages.

[dcbrown]

If you want to roll your own application/software, www.microchip.com sells a USB evaluation board:

DM163025 - PICDEM FS USB

and the MMC/SD daughter board that can be used with the above board.

AC164122 - PICtail Daughter Board for SD & MMC Cards

I've had both for almost a year, but not enough time to test the data logging software out.

A pre-canned serial data logger is also available like the Acumen DataBridge SDR-OEM-SF. It records all serial port traffic onto SD but is pricey.

I'd like a totally passive data logger that I don't have to send commands to in order to get it to log/save the data.

For debugging purposes I need not only all the raw sensor data and outputs, but intermediate steps of the code in processing the data. Its usually one of the intermediate steps that is messing up and causing problems.

Bud

[chris31]

Originally Posted by dcbrown

If you want to roll your own application/software, www.microchip.com sells a USB evaluation board:

DM163025 - PICDEM FS USB

and the MMC/SD daughter board that can be used with the above board.

AC164122 - PICtail Daughter Board for SD & MMC Cards

I've had both for almost a year, but not enough time to test the data logging software out.

A pre-canned serial data logger is also available like the Acumen DataBridge SDR-OEM-SF. It records all serial port traffic onto SD but is pricey.

I'd like a totally passive data logger that I don't have to send commands to in order to get it to log/save the data.

For debugging purposes I need not only all the raw sensor data and outputs, but intermediate steps of the code in processing the data. Its usually one of the intermediate steps that is messing up and causing problems.

Bud

The PICDEM board is like $60 and then i dont kno what the AC164122 costs. I have the designs mostly finished. The final cost should be about $30. Ill have code, design all that posted for free. And ill probably sell them at the value of the raw materials since I have some exra parts laying around.

[JBotAlan]

OK, I'll have to give some of these solutions a try.

Good point about the weight issues. I know every year we are at least .2lbs overweight...a little PIC board and flash drive are surely seen as expendable and will be ripped off ("Jake, are you sure we need that?").

I'll have to look at how big our EEPROM is; I might be able to just use that--even though using a PIC with an SD card or CF would be the funnest (wow, spell check isn't whining about the word "funnest") project.

Thanks for all your suggestions,
JBot

[chris31]

Originally Posted by JBotAlan

OK, I'll have to give some of these solutions a try.

Good point about the weight issues. I know every year we are at least .2lbs overweight...a little PIC board and flash drive are surely seen as expendable and will be ripped off ("Jake, are you sure we need that?").

I'll have to look at how big our EEPROM is; I might be able to just use that--even though using a PIC with an SD card or CF would be the funnest (wow, spell check isn't whining about the word "funnest") project.

Thanks for all your suggestions,
JBot

If you run it off teh dashboard port then it wount be any weight to the robot.

[ozrien]

Actually, we (Cross the road electronics) have a device that will allow reading and writing to/from an SD card or USB thumb drive. Powered by the same technology in USB-Chicklet, it interfaces to the SD/USB device and provides a gateway to serial rs232 port (program port) on the RC. Not only will you be able to log data into FAT32 files, but will also be able to script autonomous and PID gain control. The script can be written on any laptop with a card reader or USB port. The device is called Chicken-AID (Autonomous Interface Device). Chicken-AID will require an RC driver similar to the camera but no where near as complicated.

Omar Zrien
Chief Software Engineer
Cross The Road Electronics
Team 217, The Thunder Chickens

[chris31]

Originally Posted by ozrien

Actually, we (Cross the road electronics) have a device that will allow reading and writing to/from an SD card or USB thumb drive. Powered by the same technology in USB-Chicklet, it interfaces to the SD/USB device and provides a gateway to serial rs232 port (program port) on the RC. Not only will you be able to log data into FAT32 files, but will also be able to script autonomous and PID gain control. The script can be written on any laptop with a card reader or USB port. The device is called Chicken-AID (Autonomous Interface Device). Chicken-AID will require an RC driver similar to the camera but no where near as complicated.

Omar Zrien
Chief Software Engineer
Cross The Road Electronics
Team 217, The Thunder Chickens

It says it will be release November 06 but i dont see any pictures or prices for it on your website.

[ozrien]

Originally Posted by chris31

It says it will be release November 06 but i dont see any pictures or prices for it on your website.

Ha sorry about that, we've corrected that page. We have been focusing on the release of USB-Chicklet so unfortunetely Chicken-AID won't be released prior to kick off. We do have working prototypes so hopefully we can manufacture soon.

[JBotAlan]

Originally Posted by ozrien

Actually, we (Cross the road electronics) have a device that will allow reading and writing to/from an SD card or USB thumb drive. Powered by the same technology in USB-Chicklet, it interfaces to the SD/USB device and provides a gateway to serial rs232 port (program port) on the RC. Not only will you be able to log data into FAT32 files, but will also be able to script autonomous and PID gain control. The script can be written on any laptop with a card reader or USB port. The device is called Chicken-AID (Autonomous Interface Device). Chicken-AID will require an RC driver similar to the camera but no where near as complicated.

As ridiculously cool as that sounds (I'm bummed I didn't come up with it), I would never use a prebuilt solution like that. I understand it is meant to level the platform so less experienced teams, but I would have to build it myself first. (scampers around to get parts to copy off of Chicked-AID )

That would be nice...I probably will copy the idea...

JBot

EDIT: Just out of curiosity (if you're going to reveal any of it) is it PIC based? I've gotta get me one of those!

[Richard Wallace]

Originally Posted by JBotAlan

As ridiculously cool as that sounds (I'm bummed I didn't come up with it), I would never use a prebuilt solution like that. ...

I'm not following your reasoning there.

What is it about pre-built solutions that you don't like, and why wouldn't you use them on an FRC robot? Interpreting your statement above literally, I guess you'd buy raw stock and make your own screws? [EDIT: of course that's rhetorical. I know very well that you are part of a great team that would not let you waste time making screws. ]

Many of us have made our own components for the fun of it, or to save money, or when similar COTS parts were not available. But I can't see a good reason for making something that you could buy as cheaply, especially during FRC build season.

BTW, my day job is designing electric motors and electronic controllers to drive them. FRC rules prevent me from making custom motors and controllers for my team's robot, but even if they didn't I am sure there would be a better uses for my time during build season. Also (like many others here on CD), I have built custom wheels and gearboxes for FRC robots. But I'd only do it again if my team felt there was a clear advantage to be gained, one that could not be gained by using COTS components.

[JBotAlan]

Originally Posted by Richard

I'm not following your reasoning there.

I figured I wasn't very clear.

I like some prebuilt solutions--Victors, PWM cables, the RC/OI, and the rest of the control system comes to mind. However, I like building my own devices for more than one reason. I like building my own devices because there is a higher sense of accomplishment--I built that vs. I bought that. Second, I learn a lot when I make these devices. I don't want a "black box" on the robot that I don't know even the slightest of its internals--NO! I want to know what goes on inside that box. And, since I think a PIC would be useful here, and our controller is PIC based, it might do me some good to get my feet wet with PIC programming. So I see it more beneficial to "roll my own" hardware solution on this.

Plus, "rolling your own" is just so much cooler.

Realistically, will I use something like this during build season? Probably not. What will I probably end up doing? hooking up my lappy to the dashboard port and logging on PWMs 7ish - 12. (BTW, are 13-16 still transmitted through the dashboard port even if I don't generate their signal from code? Are they even transmitted at all?)

Originally Posted by Richard

What is it about pre-built solutions that you don't like, and why wouldn't you use them on an FRC robot? Interpreting your statement above literally, I guess you'd buy raw stock and make your own screws? [EDIT: of course that's rhetorical. I know very well that you are part of a great team that would not let you waste time making screws. ]

Can you program a screw to write to an SD card? Also, me, make a screw? I'd probably not only thread it the wrong direction, but I'd destroy 3-4 tools in the process, along with removing some fingers...never EVER let the programmer touch the machines...

So why don't I like prebuilt solutions? Because homebrewn is so much sweeter!

(hey, I'm a dreamer )
JBot

[chris31]

Originally Posted by JBotAlan

As ridiculously cool as that sounds (I'm bummed I didn't come up with it), I would never use a prebuilt solution like that.

Well, If your more into the DIY type of projects and want to copy the idea (you dont re-invent the wheel everyday do you?) I will have mine finished soon. The main problem I have now is I have no OI. So im using an cold PC to spit out packets like the OI would. Ill want to test in on the OI on kickoff day to make sure there any anything funky with it.

[Mike Hendricks]

Originally Posted by dcbrown

and the MMC/SD daughter board that can be used with the above board.

AC164122 - PICtail Daughter Board for SD & MMC Cards

Not sure if this is still relevant, but our programming mentor showed up at one of our preseason meetings with a little SD card reader similar to the one linked above. I don't remember all the details, but I believe it needed 6 Digital I/Os on the controller and you could read text files off it (his idea was to use it to hold a few pages of stuff that constantly changes like auton programs) so you don't have to recompile and reload your code so much (during programming sessons, we have students who only hold the 50ft program cable, and on command will plug it in and "PROG" the RC)

I'm not sure if he's done any further testing with it, but if you're interested (or anyone else for that matter) I can talk to him about it. I believe the cost of the board was no more than $50

[Astronouth7303]

Originally Posted by PhatMike

Not sure if this is still relevant, but our programming mentor showed up at one of our preseason meetings with a little SD card reader similar to the one linked above. I don't remember all the details, but I believe it needed 6 Digital I/Os on the controller and you could read text files off it (his idea was to use it to hold a few pages of stuff that constantly changes like auton programs) so you don't have to recompile and reload your code so much

Good luck with that. Even on the PC, string parsing is hard. On the PIC, I doubt you'll have the power or memory to handle it. What might be more reasonable would be to store autonomous in EEPROM and use a custom loader to change it. (Similar idea to Kevin's navigation code.)

Of course, you should feel free to prove me wrong.