Trouble with Programming Romi

I am pretty new to programming (especially command based) and am having trouble creating a command (or a subsystem) to drive an added motor to our ROMI (called IntakeRoller).

Does anybody have any advice? Link to our code below:

1 Like

I am on my phone so it is a bit difficult to parse everything. However, I see a few things.

The intake Subsystem does not seem to do anything. If you look at the drive subsystem as an example, it should define the motor to spin the intake and then spin it with some control logic (in periodic or in a separate method).

Once that is done, then you control it in button bindings. You could do what you have with creating a new method in robotContainer, but that is not really necessary.

Edit: To expand on this, you could look at the directions here.

Here is an example (but you may want to do on and off with two separate buttons) that assumes we have an Intake subsystem that instantiates a motor and in it, has a method (runIntakeMotor) to run said motor (which requires a double)

            JoystickButton m_intakeOn = new JoystickButton(m_driverController, 3);
              .whenPressed (new RunCommand(()->m_intake.runIntakeMotor(.7), m_intake))
              .whenReleased  (new RunCommand(()->m_intake.runIntakeMotor(0), m_intake));

Thank you for posting this question as we are going to need to figure this out on Monday, and though I knew how to do it in general, I had not gone through the steps of actually implementing it.

1 Like

I see a few things.

The constructor for your IntakeRoller subsystem expects you to pass it… an IntakeRoller? How are you supposed to construct the first one? (Chicken-egg.) It looks like you modeled this class off of the ArcadeDrive code in the template. Note that the m_drivetrain object is a DriveTrain, not an ArcadeDrive.

Your subsystem can probably be simplified. You do (probably) want to have the Spark() in there for controlling your intake motor. You want to model this class off of your DriveTrain, but with just a single motor.

Also, don’t forget to configure your EXT0 - EXT4 I/O port(s) in the wpilib.local configuration webpage.

1 Like

Don’t wait too long. We found this to be a bit more difficult than it should have been.

1 Like

Yes. Thank you. I figured. However, that is the time we have. Our members are working independently until Monday. Then, we are coming back together to put all these pieces together. I do have a chunk of time, but we also undestand that is down to the wire (and then some?).

Based on this thread, we do have a simulated version working now, but putting these things together always takes more time than we realize.

1 Like

depending on what ‘motor’ you’re using to run your ‘intake’. It might be just good enough to treat it as a Digital Output and use that directly to drive your motor.

[another thing to consider - digital out by itself is usually a LOW current output when driving HIGH, but typically as a sink, it can take in more current so you could potentially use that as well].

1 Like

Also, I was thinking about the challenge (I am assuming you are working on Frantic Fetch). I feel it may be suitable to create a method (or two) in Robot container that starts (and ends) the motor as you may want to implement it (three times if you are stopping it rather than running it constantly) in auto.

yeah our goal is to just implement a quick command to ‘turn on/off’ that motor and chain that as part of the path (we’re most likely still not able to take advantages of the full trajectory pathing due to our bad gyro drift so will be looking at alt method. Might be bringing back vision but that really drain the battery fast when using the USB webcam and we don’t have a pi-cam on hand.

1 Like

We mediated the gyro drift problem in a few ways.
We found one of the Romi with less drift.
We recalibrate using the web interface before each run (we are running the newest image, but do not yet know how to calibrate through code).
We are using the pathweaver path groups and grabbing the position before each path. So, we have a natural break at each ball.

I would caution against trying to attach a motor directly to one of the GPIO pins. They do not have the necessary current handling capacity, or the clamping diodes to protect against back EMF from the motor. This is almost guaranteed to fry your Romi controller board.

You should always have some kind of a motor driver between your GPIO lines and your motor. We are using a simple h-bridge, but you could also use a hobby “ESC” electronic speed controller, sometimes also called a “BEC” - battery elimination circuit.

1 Like

our original rc motor only had an activation current in the 50mA range so it can run it but it’s not enough to drive the shaft. so ended up using one of the ones that comes with many of the Pi robotic kit and added an output darlington driver to drive the current (ULN2003A data sheet, product information and support |