Sasquatch Robot Controller powered by Arduino

[ajlapp]

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

This new control system is a direct descendant of our RobotOpen Arduino Shields.

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.





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]

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]

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]

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]

Originally Posted by coalhot

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]

Originally Posted by McGurky

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]

Originally Posted by AllenGregoryIV

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]

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]

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]

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]

Originally Posted by ajlapp

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

Could you please elaborate on this?

[apalrd]

Originally Posted by ajlapp

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]

Originally Posted by apalrd

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/sh...d.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]

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]

Originally Posted by ajlapp

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.