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/

[ablatner]

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]

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.