Sasquatch Robot Controller powered by Arduino

[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.

[inkspell4]

What languages and ides will be supported?

[Gdeaver]

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]

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]

I believe that lab view does have Arduino plugins though

[Ether]

Originally Posted by Gdeaver

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]

Originally Posted by Gdeaver

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

Originally Posted by ferret_guy

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]

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]

No native CAN interface?

[BornaE]

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.
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]

Originally Posted by BornaE

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]

Originally Posted by Ether

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]

Originally Posted by BornaE

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]

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.