Sasquatch Robot Controller powered by Arduino [Archive]

ajlapp

26-12-2012, 21:18

We're excited to announce that we've recently created a Kickstarter campaign to raise funds for a new feature-rich robot control system based on the Arduino architecture.

Sasquatch Robot Controller powered by Arduino (http://www.kickstarter.com/projects/625182622/sasquatch-robot-controller-powered-by-arduino?ref=email)

This new control system is a direct descendant of our RobotOpen Arduino Shields. (http://www.team221.com/robotopen/)

The controller was conceived and submitted for the FRC 2015 Control System Proposal. As a result it has many of the features FRC teams would expect.

We're excited about developing this product and expanding the capabilities of the RobotOpen Arduino Library, Driver Station and control hardware. A successful Kickstart would allow us to produce these boards in a larger quantity and keep the costs low. We're targeting $250 as a retail price for the controller with an enclosure. We're offering the same product on Kickstarter for $200.

http://www.team221.com/upload/sasquatch_enclosure_concept3.JPG

http://www.team221.com/upload/sasquatch_proto_v2.jpg

We'll be updating the Kickstarter page as necessary. We hope the FRC community finds this product exciting and useful! If you do, please spread the word to your non-FRC contacts. Thanks for your support.

Andrew Rudolph

26-12-2012, 21:35

Wow! This thing looks like the first controller in a long time that's well thought out for FRC and a price that is outstanding. Arduino based means so many language possibilities, and so many great resources out there to let teams get up to speed make this a great option. Great Job!!

AllenGregoryIV

26-12-2012, 21:46

This looks fantastic and has all the features I would be looking for.

At what voltage does the board brown out? Having a 12v input spec is a little scary since most FRC robot routinely run on 10.5v or less. It it designed to run off the 24v output from the PD?

Does it have anything similar to the analog accumulator on the cRIO for gyros and the like?

Does it have a diagnostic light output for something similar to the FRC signal light?

How do you handle 24v solenoids? Do you have to run the whole board off of 24v for that to work?

Can it be wirelessly programmed?

coalhot

26-12-2012, 22:49

I have to say, I like that at least one of the members of the 2015 FRC control system proposal have put together a kickstarter and published what their control system does. I think this has multiple positives, such as it allows the community to give a response as to what it thinks of the design; and it also allows the platform to become a viable hobbyist tool if it doesn't become the next FRC control system.

I had a few questions of my own with this, firstly that it (meaning arduino) seems quite underpowered to handle any video streams/processing. I know that the current cRio, while also underpowered, still can handle more, and teams have attached other boards to process video (such as beagleboard, pandaboard, etc). My question is would it be possible to do something like 341 did this year where the video was streamed to the driver station, processed there, and then the commands given; or is it not possible?

Also, I was thinking about the number of input/output connectors on the controller, is there a way to expand them if you run out of connections? Personally, I've never filled a sidecar, but I have come close. I can imagine filling them, and the cRio has a way around that (second module, second sidecar). Is there any option in case you run out of ports?

McGurky

27-12-2012, 00:56

I had a few questions of my own with this, firstly that it (meaning arduino) seems quite underpowered to handle any video streams/processing. I know that the current cRio, while also underpowered, still can handle more, and teams have attached other boards to process video (such as beagleboard, pandaboard, etc). My question is would it be possible to do something like 341 did this year where the video was streamed to the driver station, processed there, and then the commands given; or is it not possible?

This would still be possible, depending on restrictions that could be put on by FIRST. Teams that processed vision on the Dashboard with the driver station computer did so by accessing the camera feed straight from the camera, without any processing through the C-Rio. The processed information was then sent to the C-Rio through whatever protocol the team decided worked best. (at least this is what ours, and all teams I talked to did)

This type of control scheme would certainly be possible with this controller. And personally, I believe it is best to leave the image processing to something much better suited like full computers or dedicated Graphics processing electronics like the panda, beagle, CMU etc (Albeit still under powered).

One thing that I really liked about this solution was the simple and easy to use DS Chrome plug in; cross-platform and easy to update. I also love the cost/functionality ratio in comparison to the other control options on the market.

There is a thriving community behind AVR systems (what Arduino is), and this could greatly benefit FRC teams.

Thank you 221 for opening this up to the community!

AllenGregoryIV

27-12-2012, 01:20

There is a thriving community behind AVR systems (what Arduino is), and this could greatly benefit FRC teams.

I agree with this but so much of that community is slowly moving to ARM processors. (Arduino DUE, Teensy 3.0, Beaglebone/board, etc...)

I do think that this board combined with a more powerful ARM board for vision would easily replace the cRIO setup.

dellagd

27-12-2012, 03:18

I agree with this but so much of that community is slowly moving to ARM processors. (Arduino DUE, Teensy 3.0, Beaglebone/board, etc...)

I do think that this board combined with a more powerful ARM board for vision would easily replace the cRIO setup.

Raspberry pi for robot controller! Im sure the people that produce would gladly get behind a project like FIRST.

Either the Pi or something like a pandaboard. Would be great. There isnt exactly the best community out there for the crio (If there is one at all since its mostly an industrial controller)

ajlapp

27-12-2012, 11:32

At what voltage does the board brown out? Having a 12v input spec is a little scary since most FRC robot routinely run on 10.5v or less. It it designed to run off the 24v output from the PD?

The Sasquatch operates down to approximately 4.5v.

Does it have anything similar to the analog accumulator on the cRIO for gyros and the like?

It does not. Just the standard Arduino style analog input circuits.

Does it have a diagnostic light output for something similar to the FRC signal light?

It does not have an output for a signal light. It does have a very bright tri-color LED that is used to send the "enable", "disable" and error signals.

How do you handle 24v solenoids? Do you have to run the whole board off of 24v for that to work?

The solenoid circuits run at the input voltage. If you want to use 24v solenoids then you must power the board at 24v.

Can it be wirelessly programmed?

It cannot. The Sasquatch uses the standard Arduino development environment. Our included library does include a way to define variables as parameters. You can modify these parameters from the driver station wirelessly.

My question is would it be possible to do something like 341 did this year where the video was streamed to the driver station, processed there, and then the commands given; or is it not possible?

This is the intended architecture. The Sasquatch still uses a wireless router to communicate with the driver station app. Video can be sent through this same router and displayed inside the driver station app. You could then use the driver station computer for vision processing. Alternately you could use any other board for processing locally.

Also, I was thinking about the number of input/output connectors on the controller, is there a way to expand them if you run out of connections?

There is no way to expand ports. There are however more ports on the Sasquatch than the current cRIO based system and most of the other systems on the market.

I agree with this but so much of that community is slowly moving to ARM processors.

We stuck with the Atmega2560 because of the timing for the FRC proposal and our familiarity with these chips. We are aware of the ARM based solutions and plan to expand this product line in the future should they prove to be popular.

Nemo

27-12-2012, 13:49

Can this be programmed with LabView? Or can libraries be developed to make it possible?

I can't argue with the idea of a lighter, less expensive controller. Sounds pretty good to me.

ajlapp

27-12-2012, 14:08

Can this be programmed with LabView? Or can libraries be developed to make it possible?

Not directly. Labview cannot be compiled down to a format that would run inside the Arduino processor. Labview does provide a subset of tools that let you talk to the Arduino and use it as an input/output device.

There are other graphical options, like Simulink, that can be compiled down to the Arduino.

I'm interested in exploring the Labview options as I have had a positive experience using it for FRC. It's just not natively designed for embedded solutions. We'll see what happens in the future.

Ether

27-12-2012, 15:01

[Labview] is just not natively designed for embedded solutions.

Could you please elaborate on this?

apalrd

27-12-2012, 15:08

Simulink

I would personally love a Simulink programming environment. It would make me very very happy.

How are you handling your dashboard-editable calibrations? I have some ideas on implementation, if you'd like them.

Are you doing anything to resemble an OS of any sort? At least something to guarantee loop timing?

Ether

27-12-2012, 15:13

Are you doing anything to resemble an OS of any sort? At least something to guarantee loop timing?

I wonder if something like this might work

http://www.chiefdelphi.com/forums/showthread.php?t=110149

... doesn't do time-slicing but it is preemptive with 64 priority levels.

The latest version is not free, but supports time-slicing. Maybe they'd make it free for FRC use:

http://micrium.com/page/products/rtos/os-iii

or this:

http://www.freertos.org/

ajlapp

27-12-2012, 15:25

Could you please elaborate on this?

I probably spoke too loosely. I cannot elaborate on this...but to the best of my knowledge and research there isn't a ready-make way to compile Labview down to an Arduino. There are some embedded solutions I believe, but they are specialized...similar to how Labview runs on the Mindstorms equipment.

I would personally love a Simulink programming environment. It would make me very very happy.

How are you handling your dashboard-editable calibrations? I have some ideas on implementation, if you'd like them.

Are you doing anything to resemble an OS of any sort? At least something to guarantee loop timing?

Simulink does have some support for Arduino. We have yet to look too deeply into it.

Please feel free to elaborate on your ideas about parameters. I can expand on our strategy offline.

We do have a strategy to keep loop timing consistent. It involves an internal interrupt used as a "heartbeat." Our lead software engineer is better suited to elaborate. He can jump in on this discussion.

Ether

27-12-2012, 15:39

We do have a strategy to keep loop timing consistent. It involves an internal interrupt used as a "heartbeat." Our lead software engineer is better suited to elaborate. He can jump in on this discussion.

I'd be interested in that.

I wrote a preemptive rate-monotonic kernel for an Atmega μC in C and assembly 5 years ago back when I was consulting for an automotive smart actuator project. Single stack to conserve memory, and extremely low interrupt latency and context switch overhead. I think it's in production now.

ablatner

27-12-2012, 15:44

Can you explain how an Arduino-based controller will replace many parts of the cRIO that are separate from the processor like the many FPGA's and registers?

apalrd

27-12-2012, 18:30

Ideas on parameters:

I work a lot with automotive controllers, and the way we calibrate (and integrate with Simulink, in many cases) is rather simple:
-I can use a Simulink constant block, but type a workspace variable instead of a number. I can then define the variable and type in a 'data dictionary' which defines the calibratable parameters and their default values. We usually allow normal single-value types (although not always float types depending on the processor). We can also define 2d and 3d interpolation lookup tables, with the x, y, z indexes and data.
-I can also define 'measurement points' in the DD, and they correspond to Points in Simulink (wires get a blue thingy to indicate they are measurement points)
-When I do a SW build, it compiles the list of variables and their locations in memory (we don't dynamically allocate memory) into an 'A2L' file, with the code and default calibration in a Hex or S-record file. The A2l also includes the scaling from memory to engineering units, describes what units they are, limits, and used memory regions.
-I have a 'calibration tool' which is capable of communicating with the ECU in question. This is usually over CAN, since we already have a CAN bus to use, but it dosen't have to be. It's usually a SW program on my laptop, although I also have a physical box which can read data.
-In the cal tool, I can define screens, where I create indicators to read measurement points and controls to set calibrations. Nicer programs can draw 2d/3d interpolation tables as curves and surfaces, lesser ones just show the tables as a grid of data.
-If I am working with a development ECU, the ECU will copy the entire calibration block to RAM on boot, and I can switch between the Flash and RAM calibration pages easily ("Reference" and "Working" pages). I can only modify calibration in RAM. When I am done, some ECU's can write the Flash from RAM, others I have to flash using the normal flash process. For production ECU's, I can't change anything without flashing, that's a RAM size limitation.
-I can save copies of the calibration on my computer, in Hex or Srec formats. Along with the appropriate A2l, I can read any cal as labels in engineering units, some programs provide nice dataset management, and can merge cals by label.

The problems with this exact system:
-You must use the right A2l for the software build, or the RAM addresses are wrong. We don't build often, but we still have to manually deal with this issue. Since you have an SD card, you could keep the SW build files needed to read RAM on the card, and read them when you connect to the ECU.
-You can't dynamically allocate memory with this method, unless you use something other than RAM address to identify the cals. Using a 32-bit address is more efficient than a name, and can be used directly by separate program segments, so we use this method.
-You could use Ethernet as the transport layer, all fine there.
-I can provide some more details if necessary.

inkspell4

27-12-2012, 19:09

What languages and ides will be supported?

Gdeaver

27-12-2012, 19:50

To go back to a 8 bit controller after the NI experience seams kind of retro. I'm not saying we could not run our swerve code on a 8 bit controller but, it would require some very fine crafted code. Some thing that is most likely beyond our student team. Labview may be looked down upon by many professional programmer but I've watched our students accomplish some amazing things with labview and the crio. I fear this system will make us fall backwards. I'd rather go forward.

ferret_guy

27-12-2012, 20:00

I agree with the above sentiment that this would seem like a move back. The reason I like the cRio so much is the face that it supports so much diversity and can support very easy to grasp languages like labview

inkspell4

27-12-2012, 20:19

I believe that lab view does have Arduino plugins though

Ether

27-12-2012, 20:22

I'm not saying we could not run our swerve code on a 8 bit controller but, it would require some very fine crafted code.

Why would your swerve code have to be finely re-crafted to run on an 8 bit controller?

Billfred

27-12-2012, 22:22

To go back to a 8 bit controller after the NI experience seams kind of retro...

I agree with the above sentiment that this would seem like a move back. The reason I like the cRio so much is the face that it supports so much diversity and can support very easy to grasp languages like labview

I see the argument for raw processing power, but I also know teams are going to max out whatever they are given. Teams were pegging their cRIOs at 100% with video, while ten years earlier SPAM named a robot 3-Bits for the amount of space left on their BASIC Stamp-based IFI controller. (Paging George Wallace to correct whatever part of that I surely butchered, but they really had it close.)

To me, the important thing is the system's resilience at maintaining command response. That will involve things outside the immediate purview of the Sasquatch, such as the radios, FMS, etc.--but at the end of the day, it has to be able to withstand boneheaded robot design decisions. (Outright abuse is a nice-to-have.)

The second most important thing is service and documentation. IFI killed it with this back in the day; with PDFs off their website, you could wire up the control system, apply power, and drive without even necessarily hooking up a computer to download code. And at events, their reps were incredibly helpful. The CSAs have been great since then, but there's something about a person empowered to pull a part, break the warranty seals, dig in, and fix it. (Actually happened to a team of mine with the spade power terminals. Fixed in 10-15 minutes, and that was the year of the radio reprogramming.)

Everything else--languages, I/O, weight, cost, schedule of more parts--is far more flexible in my eyes when those first two points are hit.

inkspell4

27-12-2012, 22:39

I wonder if the sd card could be used as spare/extra ram allowing for more processing power.

Also how hard would it be to over-clock the microcontroller.

techhelpbb

28-12-2012, 10:23

No native CAN interface?

BornaE

28-12-2012, 13:31

The Atmega2560 should be able to handle anything robot related thrown at it short of video processing. We used one this past summer for the sparkfun AVC.

video here. (https://www.youtube.com/watch?v=63llcrecfSk&list=PLDC13B06F9FD3CBC9)
This involved:

bringing in the info from a GPS and a gyro.
Doing all control loops for autonomous navigation.
Tunable parameters over a wireless link.
Send telemetry information over the wireless link for debugging

However, beware that the Arduino does not support double precision math. Everything is done single precision floating point.

Ether

28-12-2012, 15:07

However, beware that the Arduino does not support double precision math. Everything is done single precision floating point.

I'll toss this out to stir up the pot: if you need double precision floats for your FRC software, you should re-think what you're doing.

BornaE

28-12-2012, 15:32

I'll toss this out to stir up the pot: if you need double precision floats for your FRC software, you should re-think what you're doing.

The problem is you can define a variable as double and it is stored in memory as a double however the math is done as single precision. No warnings from the compiler or anything that would tell you this is happening.

Main reason this was an issue was that I was using doubles to do GPS lat/longitude calculations and it was being rounded/truncated which was causing accuracy issue.
To fix this, I stored the GPS lat/long x 10^7 as a 32 bit integer and take the difference with integer math and do the rest in floating point.

Another place this may be useful is gyro integration and the offset. However single precision works fine.

apalrd

28-12-2012, 15:46

The problem is you can define a variable as double and it is stored in memory as a double however the math is done as single precision. No warnings from the compiler or anything that would tell you this is happening.

This is really really common in embedded systems.

The compiler allows a Double because it's a valid, common type, but converts it to Float because it can't do Double math in hardware. I'm not actually sure that the Arduino's processor is doing any float math in hardware, so the single Float you ended up using could have been a software float (I'm not sure).

Usually it's in the SW toolchain documentation, and fairly easy to miss.

As for the gyro, it's probably much more efficient to do the math as a signed int or long and stay in ADC counts as long as possible. Unit conversion (especially divides) are usually very expensive operations on embedded systems, so they usually make up units to use signed or unsigned integer math in whatever units are convenient. This leads to heavy use of ADC counts as real units, percent as a signed char (127 being 100%), and angles as 'brads' (0-255 for a circle of 360 degrees). Also, for precision, many algorithms for embedded systems focus on using the less expensive bit shift rather than divides.

All of this cRio programming has made everyone really lazy with their math. It also seems to make it OK to add tons of layers of abstraction with no care about efficiency. It makes me sad to see relatively simple robot code running at only 50hz or so (realistically slow for a control loop) use the entire processor, without thinking about vision.

ajlapp

29-12-2012, 11:40

Can you explain how an Arduino-based controller will replace many parts of the cRIO that are separate from the processor like the many FPGA's and registers?

It is not designed to be a cRIO replacement. We weren't necessarily interested in replicating it's functionality...only offering a complete controller solution based on a development environment with a large community and broad appeal.

What languages and ides will be supported?

We prefer the basic Arduino development environment. As with all Arduino boards any C/C++ constructs can be used as long as they work with the AVR compiler. Simulink has a complete environment and a thriving community. Labview has some tool sets that allow you to interact with the Arduino. There are also many other projects on-going that have various levels of support.

Everything else--languages, I/O, weight, cost, schedule of more parts--is far more flexible in my eyes when those first two points are hit.

I agree with this viewpoint. The cRIO though powerful, has many open issues. This is likely one of the reasons FIRST is looking for new solutions. It has always been my understanding that NI was sort of short on time when they initially got involved and that they would have preferred a different solution over the cRIO.

Regardless, we believe in open-source. Everything about our new system is completely open and documented. We're looking for users to modify hardware, add firmware and generally improve the product over time.

No native CAN interface?

No. We eliminated CAN to help keep costs down. The hobby market hasn't fully embraced CAN either. We proposed to use a 2CAN to gain access to a CAN network via ethernet. We are also considering licensing the technology inside the 2CAN for future projects.

The Atmega2560 should be able to handle anything robot related thrown at it short of video processing.

Exactly. Outside of FRC we build many robots, especially swerve/crab robots. We run all of these using Arduino mainboards...this is the main reason why we chose to build our own system. It's smaller, cheaper and more powerful than those that we've been assembling with COTS parts.

I'll toss this out to stir up the pot: if you need double precision floats for your FRC software, you should re-think what you're doing.

100% agree again.

One part of our proposal to FRC was to consider including multiple processor options for teams. Many teams, especially those just getting into FRC need only basic functionality. I think many people would be disappointed to learn how many teams are simply fielding a remote controlled car...meaning no sensoring, no feedback, no software based decision making.

We had hoped to bring Arduino into FIRST because of it's popularity in the education community. Being successful in FIRST is increasingly dependent on your ability to design software. Having familiarity with the architecture on day one can be a powerful leg up for teams without a software expert on their staff.

Foster

29-12-2012, 11:59

Sparkfun has a good Arduino math tutorial (http://www.sparkfun.com/tutorials/317) that talks about bytes, ints, float and longs. They do some very simple math and give you size and time.

It's interesting to see things that we did in the 70's and 80's are coming back. Yay integer math!!

nyaculak

29-12-2012, 13:35

I am very excited about this proposed controller. I really hope we use this for the new control system. I currently have a RobotOpen shield, which I plan to start using after the upcoming build season. It would be really exciting to see the (expensive) cRIO being replaced by a cheaper, open source controller.

I was reading the proposal request from FIRST, and it seems that the new control system will be required to support at least two languages (at least one being a visual language). I expect you to use the native Arduino-C language and environment. What are your plans on the visual language? I found an Arduino and LabView bundle (https://www.sparkfun.com/products/11225) on Sparkfun a little while ago.

For the future, I think it may be worthwhile developing an image-processing board that is made to work nicely with the Sasquatch. My team likes to use the Beagle products for our image processing. I believe something that falls in between the BeagleBone and the BeagleBoard should be powerful enough for the image processing that occurs on the FRC level.

inkspell4

29-12-2012, 13:53

I actually have used labview to program the Arduino all it takes is a simple plugin. It would most likely be configured to work if someone would take the time to make it work.

ajlapp

29-12-2012, 15:15

Tom Line

30-12-2012, 11:58

Tom Line

30-12-2012, 12:02

Joe Ross

30-12-2012, 12:12

Where did you find the control system proposal? I couldn't find it with a quick google.

http://www.chiefdelphi.com/forums/showthread.php?t=108083

techhelpbb

30-12-2012, 12:15

Unfortunately this will not be a reality. We were informed on Friday that we didn't make the first round of cuts. Hopefully a solution as simple as the Arduino will prevail.

We proposed Simulink. It will compile down to the Arduino and there is official support from Mathworks.

Simulink + Arduino (http://www.mathworks.com/academia/arduino-software/arduino-simulink.html)

That said we have focused mainly on the native Arduino environment.

Since you have openly acknowledged this I'll add my 2 cents.
Myself and another party also presented a proposal for a control system to FIRST.

We also were told Friday that our proposal will not be making it to the second round.

In our case it was understandable. We don't currently have the product in the market place and while our core processor, like the Arduino, was available at Radio Shack FIRST had some concerns about our system not be established enough for their needs.

We were able to self fund the effort for the most part but like yourselves we lacked specifics from FIRST about the enclosure.

On the plus side within 24 hours I was able to locate an alternate place to sell the system for a slightly different purpose and that means we have sufficient cause to continue our project and maybe in a few years FIRST will still be interested. Our system was specifically designed to weather time so really regardless of how many years FIRST waits when the time comes we'll have something current and timely to show.

Having looked your product over I think it's interesting. I wish you all the best in getting it out there and funded and I'll even toss you a few bucks towards that end. At the very minimum your approach to solving the issue of the graphical language was different from ours fundamentally. I was going to approach that by creating a construct from scratch even though there's already a drag and drop programming language and ladder logic programming translater available for our target CPU.

I won't distract from this topic with specifics on the alternate system, I just wanted to offer some collaboration and maybe some comfort to a fellow traveller. Keep the faith and march on cause we'll be on that same path.

techhelpbb

30-12-2012, 12:19

Where did you find the control system proposal? I couldn't find it with a quick google.

The proposal link is in the FRC blog:
http://www.usfirst.org/roboticsprograms/frc/blog-08-29-12

We submitted a 16 page response and had 5 drawings and a brochure with our response and it wasn't easy considering the timelines.

In any event it was interesting and we thank FIRST for taking the time to look it over.

ajlapp

30-12-2012, 16:15

Having looked your product over I think it's interesting. I wish you all the best in getting it out there and funded and I'll even toss you a few bucks towards that end.

We appreciate the support.

We crafted what I felt was a strong proposal that clearly addressed every aspect of the request, though we only submitted for the Mobile Robot Controller portion.

We were able to satisfy nearly ever technical request and exceeded the required number of I/O in each category excluding those like CAN that weren't applicable.

We have "partners" to some degree in this process, so I'm quite confident that we'll be launching this board in the near future. We'd like to successfully Kickstart so that we can begin servicing a larger group of educational professionals and hobbyists.

Like all small companies we are eager to grow. We still consider ourselves a hardware company, but Sasquatch and our previous Arduino shield efforts lead me to believe that we are headed towards the control system market with a good head of steam.

techhelpbb

30-12-2012, 16:46

We appreciate the support.

Not a problem. I noticed that your Kickstarter seems set to be over $15k or bust by Jan 25. If you do not make that goal please contact me and I will instead send you the money outside of Kickstarter.

I only asked about CAN because I know Atmel has CAN transcievers integrated with some AVR, Mega and Xmega products. What we used has no purpose built integration. We added all special functionality by peripheral. I have a long relationship with Atmel and their products. I was just surprised considering a selling point is the availability of the CAN without adding a transciever like I did.

We hit all the big selling points as well. Heck we had a separate radio link and enough room to scale out to a small supercomputer. We also went in with plastic injection companies and existing electronic production floor. We just could not demonstrate market place sales for a hobby control system. I have no regrets about that there was no way to create that from the time they expressed interest to the proposal date it really did not matter what we wrote.

I still want to pursue a community motor control module (as stated clearly in the proposal) and now that I do not have this added pressure pulling me different directions I can continue to work on the information technology that will advance on educating the market on various things without short deadlines risking compromise on that very vital point.

Dad1279

30-12-2012, 18:32

Unfortunately this will not be a reality. We were informed on Friday that we didn't make the first round of cuts. Hopefully a solution as simple as the Arduino will prevail.......

I'd like to see a simpler controller also. I pledged one on the kickstarter page, and will do another as soon as I figure out how. ;)

pmangels17

30-12-2012, 22:28

Hey guys, I guess I'm the only mechanical guy on this thread. Basically, all I can see is cheaper, lighter, and smaller than the CRio, which would be awesome. Also, I would pay $15 dollars for a shirt and some stickers anyway, so I pledged. I think it's awesome that you are doing a robotics kickstarter on here and I love the thought of investing in the future of FRC. With that said, good luck to you, and I hope this product succeeds as well as it promises. That is the mechanical guys 2 cents, so thats about all I nkow on the stuff, but goodluck.

You guys (221 robotic systems) have some rocking products, and from a guy who build a crab drive as a freshman on a build team of freshman and sophomores, I know how difficult it is to do, but you guys make it look easy. Because of that, I have no doubt that this will be a high quality product, and although I won't be a team member when it hits, I cannot wait to see it come when I am a team mentor. Good luck to you guys in all your FIRST endeavors.

Mike Copioli

30-12-2012, 23:02

Anthony,

Does the name Sasquatch imply that it has large footprint?:D

Sorry....I could not resist.

Gdeaver

31-12-2012, 07:59

So 2 proposals were turned down. Now I'm very curious. What platforms made the cut? What may we be in for 2014? I should stop worrying about 2014 and focus on Saturday. The insanity is almost here.

Foster

31-12-2012, 08:22

cRio in 2014, that's been announced. According to the timeline, final choice is to be announced spring of 2014 to give 30 weeks of mfg time.

So, in 2015 you will be programming on rock solid 2012 technology. We went to the moon on 4004 level chips. Lets hope we get the Mars Rover chips, built around a radiation-hardened BAE RAD750 microchip operating at up to 200 megahertz. Each computer is equipped with 2 gigabytes of flash memory, 256 megabytes of random access memory and 256 kilobytes of erasable programmable read-only memory. If nothing else we KNOW it can take video!

Therefore, focus away from Sasquatch and other ilk and towards Seals that are balancing tetras that have Heidi's photo on three sides, and remember the ones playing music are the bonus ones. So go eat dinner, it's a long season.

techhelpbb

31-12-2012, 10:57

The interesting part will not be who got into round 2. It will be to see if anything we proposed makes a dent in the outcome. While we wrote that proposal we specifically made the attempt to not evangelize a particular product because of the high risk of the lock-in that goes with it (that was mentioned in our proposal directly). There was no reason one couldn't take the radio module as we proposed and connect it to the Atmel based board in this topic (in fact at the core of that radio prototype is currently an Atmel AVR chip). We weren't trying to say that the Atmel is better than the PIC, is better than the 68k is better than x86. We wanted to produce whatever we could that best fit within the context of the problem and the perspective of 'voting for best' evolves outside of FIRST as people may love Arduino this week and fawn over XCore next. We can't make everyone happy all of the time...but we can make it so you can take the blue Legos out and put the red ones in.

Our proposal said right in it we would encourage vendors to specifically do exactly what I'm giving money to do right now (I am putting my money where my mouth is). To grow specific solutions where there is market interest.

I've got really no problem letting FIRST make off with the concepts from that proposal. If they have some other vendors that they are more comfortable dealing with have a ball with it. Course doing so will require those other vendors to have interest in being open and directly accessible. So there's a better than good chance business interests will intervene because that effects the technology lock-in that allows for greater profit.

I'll be curious to see what comes from showing our cards like this.

ajlapp

31-12-2012, 11:22

Does the name Sasquatch imply that it has large footprint?

Very funny. It does not imply that. In fact the Sasquatch is quite small, about 5.5" square and less than an inch tall.

The name has no specific meaning. We decided to go with mythical monsters as our naming scheme for this line of boards.

So anything we create inside this Arduino powered family will get a monster name. :)

billbo911

31-12-2012, 12:38

...
So anything we create inside this Arduino powered family will get a monster name. :)

I can't wait to see the Jabbarwocky board!

PhilBot

31-12-2012, 16:40

I actually have used labview to program the Arduino all it takes is a simple plugin. It would most likely be configured to work if someone would take the time to make it work.

Isn't the Arduino / Labview combination simply using the Arduino as a remote perhipheral to the PC...?

That is.. All the real computation/display is done on the PC, and the Arduino is a slave device communicated with via Serial Data. So all it provides is signal in/out.

So the Arduino cannot run stand-alone in this mode....

----

This was the case when I first heard of using the Arduino with LabVIEW, I was just interested to hear if it had changed.

other comment...

BTW, if you want an example of LabVIEW running on an ARM processor, how about the LEGO NXT :)

Greg McKaskle

31-12-2012, 17:19

Isn't the Arduino / Labview combo ...

Yes. The typical involvement is to use the Arduino as an I/O unit. It is possible to target it via the embedded tools, but that involves generating C code from a LV diagram and then running that through additional development tools. This is reasonable for experienced developers, but the debugging and specifics of execution can be somewhat complicated. It is also a subset of the LV language, and the execution is not necessarily the same as desktop and RT LabVIEW.

The LEGO Mindstorms NXT is indeed an ARM7, and NXT-G is a pretty faithful version of LV, but the execution is done with a virtual machine rather than generated code. This works fine for the intended user, but it is actually rather slow, even for an ARM7.

Greg McKaskle

ajlapp

01-01-2013, 18:53

It seems that Simulink is the most complete solution available if you're interested in graphical programming on the Arduino.

Simulink Press Release (http://www.mathworks.com/company/newsroom/MathWorks-Announces-Built-in-Simulink-Support-for-Arduino-BeagleBoard-and-LEGO-MINDSTORMS-NXT.html)

daniel.mcinnis

16-11-2014, 13:52

We can get it connected to the driver station for a little while and then it disconnects. and when looking at network connections it flickers between connected for 1/4 of a second and then goes unconnected for 3 seconds, then back to connected again and continues the cycle, so we can't get it connected long enough for the sasquatch to work.

we've tried different ethernet cords, wireless or wired and multiple laptops, anyone have any ideas?

ajlapp

16-11-2014, 14:18

Please email me directly and we can try to debug your issue.

Anthony@team221.com

EmileH

17-12-2014, 15:23

It seems as though in RobotOpenDS the joysticks are always in a different configuration. In our programming, we have the first 2 joysticks set up as drive sticks on a tank drive. The 3rd item is a Logitech gamepad for the operator to control a shooter (game is 2012 rebound rumble frc). For some reason the gamepads/sticks all show up in a different way every time we start RobotopenDS. The first 2 joysticks usually initialize properly in slots 1+2 however an "unknown gamepad" usually shows up in the third slot, and after that the Logitech gamepad shows up in slot 4.

Sometimes "Unknown Gamepad" is first and the other 3 follow, and sometimes the Logitech Gamepad comes up first of the 3 and joysticks follow.

My question is - is it possible to rearrange the sticks somehow, similar to like in the 2014 FRC Driver Station. At this time we reprogram the Arduino code to the stick config every time this occurs which is a large time consumer.

Also, "Unknown Gamepad" is defined as vendor id=04f3 product=0060, which I searched to find that it is showing an Elan product. This is likely either my laptop's touchscreen or touchpad.

Is there a way to remove this or hide it from the driverstation? I have tried uninstalling the device from device manager but it still has yet to work.

Emile

ajlapp

17-12-2014, 16:29