Looking at the roboRio I see only 4 Analog inputs on the controller itself and 4 available on the expansion port. This seems rather limiting. It’s not like some of the sensors give us a choice on how to interface to the controller.
What are you doing that requires 8 analog inputs? There may be other ways to accomplish the same goal without going to the complexity of an additional microcontroller.
Talon SRX also has a single analog input. That might be another way to get the analog voltage into the RIO (over CAN bus). You don’t need to use the sensor for closed-looping, you can just use CAN bus to get more analog inputs that way.
The analog in is 3.3V max but with the analog encoder breakout, you can wire a 5V signal (the breakout scales it to 3.3V).
Default update rate is 100ms, but that can be overridden depending on language. Also if you “select” the sensor programmatically, you can get it at 20ms per update.
Talon SRX always sends the analog value even if its not selected. See software referenc manual for details. But you can always call the getanalog* functions.
There are several ways to extend the IO capabilities of roboRIO. The use of I2C and SPI (both options on the MXP connector as well) and communication protocols such as CAN give a lot of flexibility. It is an excellent opportunity for the development of “value-add” accessories for the control system.
Let me stipulate that I am finding this problem late and that I should have discovered it sooner. I assumed the new shiny FIRST controller would come with enough IO to support using all the great new sensors that are becoming available to FIRST teams.
Philosophically, we are planning to have a pot provide analog position for pretty much every motor we’re using (except for the ones that drive the wheels, which use quad encoders, of course). Given this philosophy, it is really easy to use more than 8 Analog input channels.
**Does anyone have a solid solution to this 8 ADC limitation? **
I am trying to decide if I should use an Arduino and if so, then which one?
Is it legal to use a Leonardo powered off the roboRIO’s USB? If so, does the roboRIO have drivers that recognize he Leonardo’s USB Serial Port? I know others have suggested using I2C to communicate with the roboRIO, but it seems to me that it would be simpler if the roboRIO code can get to Leonardo’s USB Serial Port.
Another option is the REV RIOduino. Has anyone had luck using this? We are using navX MXP card which may block this solution.
My team needs a solid, reliable easily implemented solution without a lot of fuss and muss. I am sure that this is not a unique problem. If you have figured this out, please share.
Joe J.
P.S. I don’t want to hijack this thread but if we go with the Adafruit ADC option, what about powering it? Can I take power from the MXP or do I need to go through a fused line from the PDP as R30, R37 & R42 (collectively) imply?
Looking at the pinouts, it looks like the REV RIOduino passes through all the MXP signals so I may be able to plug the REV RIOduino into the roboRIO then plug the navX into the REV RIOduino. I have two concerns. First, will they even physically fit together (see photo attached). Second, both want to use the UART lines – The roboRIO TX line is no problem as I can have them both listen without a conflict. But I will have to let one or the other use the roboRIO RX line. Never a dull momemt.
The easiest solution I can think of would be to add a 2nd RIO to the robot and transfer the data over Ethernet to your primary. It’s costly, but meets your requirements. Short of that, the adafruit device looks interesting (I’m now investigating this for us for next year).
I don’t have any experience with the items you listed outside of the NAVX, but I won’t let that stop me from throwing my opinion out there.
The REVDuino looks like a good option because it does state that you can stack the MXP boards using the provided connector. You could use I2C to communicate between the roboRio and the arduino to avoid any conflict in the UART. There are enough threads here on that very topic that it shouldn’t be too difficult.
The I2C breakout board is intriguing. You should be able to power it using the 5V from the VRM. Seems like a cheap and simple solution.
I really hope you can power through the MXP. The NAVX we are both using is powered with it.
Talon SRXs are really the best option to extend the analog capabilities, but I’m guessing you aren’t using them if you’re still looking for more analog ins.
I know that wasn’t super helpful. Maybe somebody can chime in who has some experience with those devices.
Suppose you have a lift? It would be nice to know where it is, yes?
Maybe you want to know where a tote is as try to align to it for a pick up or a drop off? Switches are nice, but analog values seem better don’t they?
How about a chassis something akin to this one? Sure would be nice to know which way your wheels are pointing, yes?
Maybe you have something for picking up cans? Sensors to help position things or to discover the can location add up.
How about a gyro or two together with a 3 axis accelerometer?
Getting over 8 analog inputs seems pretty easy.
As to encoders, they are great but they have the problem of not knowing where they are when you wake up. I’m not saying that FIRST did a lousy job preventing brown outs with the new control system but I am saying that I wouldn’t bet my season on the robot never going dark momentarily during a match.
Absolute rotary encoders don’t have this problem. Models with many different types of digital output are available: parallel Grey code, I²C, SPI, synchronous serial, etc. A quick look at the Digi-Key catalog suggests that something appropriate for an arm or swerve steering sensor costs about $25 (which is admittedly more expensive than a good potentiometer).
But you need to bring your toolbox up to date. The Talon SRX motor speed controller has sensor inputs built in, and that’s a simple way to add more analog inputs exactly where they are needed.
The RIOduino does come with an extra connector giving you the ability to stack another MXP board on top. However, it is unlikely that the navX will clear the shield headers on the RIOduino.
I certainly see no difficulty in making a robot that wants 8+ analog inputs. One of our earliest analyses with sensors was to figure out which things we could do using DIO or a camera, and we managed to get down to four analogs (two rangefinders to square up on totes, a tape measure potentiometer for the lift, and a gyroscope).
There are a variety of Arduino solutions, including my favorite, the sparkfun pro micro which can give you four analog inputs in a package not much bigger than a stick of gum, and send it over I2C or USB or probably a DIO line if you were willing to write a driver. Their pro-mini has 8 Analog pins and isn’t much bigger, and only costs $10, though it does not have USB. If you need many more than that, the Leonardo and Due support 12 analog inputs, and the Mega has 16 analog inputs. When driving an arduino on an FRC robot, I would advise an external regulator, or at least some sort of voltage divider so you’re feeding the tiny on-board regulator between 8 and 10 volts rather than over 12. If you hurry to a closing Radio Shack, you can get one of theseon closeout.
In addition to Arduinos (look at the micros as well as the original), you could use an xBee module, which I believe can have 7 analog inputs. You wouldn’t be using the radio on it, just sending the inputs to the RIO. Disclosure: I’ve never done this, but it seems like it should work.
I’m not familiar with STAMP or the full variety of boards out there, but a bit of googling should turn up a dozen different ways to get there.
Another point to make: you don’t need to sample and pass all the digital data back to the RoboRIO. You could put some of the conditions that the analog value triggers into say an Arduino.
So for example:
RoboRIO tells Arduino that the upper limit it 100 and the lower limit is 25 (out of 8 bit A/D).
Arduino communicates back when the trigger limits are passed to the RoboRIO.
In this way a really silly number of analog inputs can be serviced because of the coprocessing capability added.
I’m sure it’s not a surprise, but I’ve been using Talon SRX’s for my analogs when testing things, but honestly its because my sensors are close to the Talons and I’m lazy when it comes to wiring. Also 20ms was sufficient for what I was doing at the time. Also I like being able to use the self-test in the RIO web-based config to quickly-peak at sensor values (Self-test works even with no robot code, I love that).
What do you think the fastest resolution teams typically will need?
If you need faster than say a sample per 10ms, then the MXP extensions might be better, though I haven’t actually used them yet.
EDIT : FYI, I saw your post about your budget. But I figured I’d chime in anyway for teams that did have SRXs.