I’m working on a University team trying to achieve position control of a BDC motor. We are using a Spark Max with the REV through bore encoder connected to the encoder port. We have not started working on the position control yet, only setting up the encoder with the controller.
We are having issues with tracking the encoder position on the telemetry page. When the encoder is rotated clockwise from home it shows a rise in values with 1 equivalent to a full rotation. When rotating the encoder counterclockwise past home there is a spike on the graph all the way to 270. When rotated clockwise back past home the value drops back 0.
The encoder has been tested with a VESC and works properly. Two separate controllers have also been tested and the issue persisted.
I haven’t been able to find a solution for this online and am waiting to hear back from REV support.
Thanks in advance for any help.
Connecting the PWM encoder only works one way – through the 10-pin port on top of the SPARK MAX, and you then need a specific set of connections. You do not use the port on the end (the one where a NEO or NEO550 would connect). The easiest way to get this connected is to obtain a breakout board that is directly designed for this application: Absolute Encoder Adapter - REV Robotics.
It sounds as though you are using the encoder as an incremental encoder, which requires a different set of connections. This works through the data port (the one on top), and might work through the connector on the front (I don’t have any experience with this configuration). But, this largely depends on the SPARK MAX firmware. What you describe sounds like what can happen when an incremental encoder wraps around the counter.
Make sure you are on the latest SPARK MAX firmware. There are some config settings that could make a difference here. When you send something to REV or post here, it’s often helpful to detail exactly how you have things hooked up and what config settings you have tried.
There are a lot of permutations: Using Encoders - SPARK MAX.
The encoder is ABI, it’s the REV through bore encoder. I tested it on the top port with the alternate encoder adapter and the same issue still occurred.
[Crossed messages with an edit I was doing went you sent this – sorry!]
The encoder is both ABI and absolute. There are a number of options for connecting it, but it does sound as though you have at least the AB inputs connected – I don’t think SPARK MAX really pays attention to the Index signal, but don’t know for sure.
The issue sounds like wrap at zero, where the counter normally goes negative, possibly combined with signed/unsigned number particulars (where a small negative number appears as a large positive one).
Dear @nuttle and all the cool people here.
I work with Dominic. What we are trying to do is really simple. I am a bit surprise how long it is taking us to try to do this.
Basically, we are trying to replicate a “big RC like” servo so we can do a hardware shake-up on an Autonomous evGoKart we are developing at UC San Diego. We are making a big RC car first so we can test & stress the mechanism while the software is being developed on a 1/5 scale robot. The usual, catch 22; HW and and SW gating each other.
We have to use a DC motor because it is integrate with our steering mechanism. We have the Rev Robotics Spark Max and the Through Bore Encoder - REV Robotics (Through Bore Encoder) set as an absolute encoder (Duty Cycle close loop) encoder. The visualization of the absolute encoder and resetting the zero works.
We can control the position using the USB and Rev software on a Windows Machine.
We don’t see setting where to map the values of the PWM/PPM input from an RC controller to the range of the “servo motor” (DC motor with the encoder). When we plug the Rx RC radio the Rev Spark Max does not move the motor to a position to wait to move. RC servos work just fine at the Rx radio.
I don’t see an option to see the PWM input at the Rev software. I would love to be able to map the input values to motor position.
It seems Rev claims we can use PWM as input. I thought this would be easy )0:
Just assume we will need to use a RC controller with PWM, the CAN common is another discussion. We control our actuators with CAN using VESCs. For now we need PWM.
It seems simple, we could not find a tutorial how to set the REV Spark Max for position control with PWM input (e.g., RC controller).
Thank you,
Jack
I doubt the standard Spark Max firmware has this capability. Other PWM based motor controllers in FRC always use speed-based control for the PWM input, not closed loop servo control, so I’m pretty sure it was not a design consideration for the Spark Max firmware to have an option for that mode of operation with a PWM input (any closed loop servo operation is likely only available through CAN). If you reach out directly to Rev, they may be able to help you with a custom version of the firmware.
Dominic called them.
“the engineer is out supporting a competition” …
I was at an event all day today (and yesterday and tomorrow). Someone from REV was at our event. But, I think @Peter_Johnson nailed the answer.
Thanks.
I would like to know for sure that the REV Spark Max does not support PPM for position control, like a RC servo.
And since it does not seem to allow CAN from embedded devices yet, we will need to move on to another controller.
The application is not for FIRST.
p.s. I was a judge last weekend at the San Diego regional. Have been around FIRST on and off since 1994.
“
Overview
This repository is for the CANBridge software that is run on non-roboRIO platforms.
About
Generic CAN Bridge emulating FRC netcomm CAN driver for connecting a PC to the CAN Bus with WPILib 2020+ and SPARK MAX (FW 1.5.0 or higher) or other drivers, currently only supported in Windows.
You might consider using an Arduino, or similar single board computer, as a stop gap interface between the Spark Max controller, the through bore encoder, and the RC receiver. This setup would not use the advanced controls of the Spark Max, but I think it would get you a usable temporary control system.
There are many examples online (like this) of using an Arduino to control the position of a DC motor using encoder feedback.
In your use case, the Arduino PulsePosition Library can decode the RC receiver (if it supports Pulse Position Modulation). The encoder absolute position output would be connected to an Arduino input. The Arduino would run the PID loop and generate PWM signals that feed into Spark Max (the Spark Max auto-senses PWM control versus CAN signals) to control the motor speed and direction.
RB
Have you looked at the CTRE can devices with a Canable USB ADAPTER? Phoenix docs have instructions for running the phoenix hardware with a Linux Computer (or Jetson/raspberry pi/other Linux sbc) and I have done this myself for NON-FRC stuff with FRC hardware. You write your final code in c++ but it uses the phoenix motor control libraries with position control, etc. You can use an adapter to get the encoder into the talon SRX if you use that and it’s less wiring to the new SBC for your encoder data.
Downside over Rev was cost but upside is it can be used outside of FRC easier I think. I guess other downside would also be having to support can but that’s the canables job or if you have the canivore. That adapts can to USB so not using pwm/ppm control directly isn’t deadly, you can still take in rc data and pass it back out as can data or I believe the Talon SRX can also accept PWM input but then idk how you get the position data out
Thanks folks.
I sincerely appreciate you taking the time to reply and give ideas. The whole point of trying the Rev Spark Max was that it seemed plug-and-play. I sent the students that direction thinking it had all we needed based on what I read on their website. I said it supported PPM/PWM input. I assumed it would not have limitations on that what it really meant. That is OK, this discussion may help others.
This week/weekend was our window to shake-up the mechanical assembly using an RC controller before we go with our regular control system. Again, I hope this discussion may help others in the future outside the FIRST and VEX world that want to enable quick mechanical assemblies test before the integration and keeping in mind the current firmware limitations of the Rev Spark Max.
Our general motor controls, except for the full size vehicle like the Indy Autonomous Challenge (IAC) is based on VESCs. We use STM32s with RTOS for our real time controller that talk CAN to the VESCs and other actuators and do the I/Os as you can guess. On the top of that ROS2 to the LIDARs and cameras.
Next year we are planning to expand and open the autonomous evGoKart competition to high schools. It is fun and probably less expensive than FRC. Our design is all open. It should help teams to start quickly.
Today we will get back to test a VESC. Yesterday I was able to see the encoder clean signal on it, and I could use PPM to control the DC motor on duty cycle and current. More over, the motor goes back to the steering position if I move it by hand. We will see if someone will show-up at the lab today to tune the PID(s); this coming week we have the students back from Spring Break at UCSD. We will get back to our RTC controlling the brushed and brushless motors.
Thank you. I really like the community feeling here.
Jack
The reason this is the case is due to the frc rules historically. When CAN was first brought around, the rules required that any closed loop control required CAN. When controlled via PWM, they were required to just be speed controllers. So for FRC, there was never any reason to support any other modes with pwm input. By the time that rule was relaxed, CAN was so universal across FRC that there was no reason to support anything more on PWM.