Some help with Romi and implementing general features

[Mr.R_2]

Hello,
We managed to purchase a few Romi robots, and they are incredible. I am wondering if someone could help with some issues we are having.

I am posting here because I do not want to muddy up the Romi git with issues that could either be…
…our fault in programming, or
…known issues.

Here are the issues we are noticing…

1. We are having difficulty with the Robot Arm Kit (which is on sale if you look here).

We can run any of the servos individually, but if we have more than one plugged into the Romi at once, the robot is fine under normal circumstances (driving), but the robot loses connection upon trying to move the servo we are trying to control (this is true even if only one Servo is instantiated at the time).

The only errors we see are a recurring brownout message (even without the servo plugged in with fresh batteries). We are using the Pololu NMh batteries.

When we lose connection, we get the following message in the terminal.

connection reset by peer
Now for the weird part. We also have many Vex motors and a hobby tt motor. We can run a claw bot servo with a vex servo and an old Vex 3-wire motor (max stall is 1.5 amps on that one, but there is a built-in thermal fuse) or tt motor fine (until a true brownout happens with low batteries).

The Analog Input does not seem to work. We tested with the analog in of the Pololu servos and a Vex Line Tracker. When using either of these, Anaolg.getVoltage() returns zero.

Anyway, I was wondering if anyone had any insight or knew where we should begin troubleshooting.

In creating our programs, we noticed similar disconnect issues with any runtime error (we may or may not have created a race condition accidentally).

We have thought it may be nice if there was a way for a better terminal to see error messages on the Romi hardware, but when communications drop, that has obvious difficulties in implementation. I wonder if there were a log system that could be helpful.

Our code is posted here.

[zeequeue]

For the Romi Arm: The standard size servos used to manipulate the arm can draw quite a lot of current, especially when stalled. Since the IO channels draw power from the Romi board by default (via the 5V jumper), this causes a brownout, which will cause the Romi board (and at times the Raspberry Pi) to reboot. The connection reset by peer message is an indication that the Raspberry Pi itself rebooted, thus severing the WebSocket connection.

For Analog Inputs: Are they plugged in to the appropriately configured Romi ports? The Web UI allows you to configure the channel functions (and shows the WPILib channel numbers). Could you also post what your IO configuration is for each of the 5 EXT pins?

The Web UI also allows you to view the Romi console (you’ll have to enable it) and any errors from the Romi side should show up in there

Edit: If you have an external 5V supply, you could remove the 5V jumper from the Romi board and attach your external supply instead (e.g. a battery + voltage regulator). Be very careful about polarity though!

[Mr.R_2]

Thank you. I will try tye VBat instead. Do you know the current limit on VBat?

As for analog input, we did set up A0 and A1 in the web interface.

[zeequeue]

VBat might be a little high (it’s 7.2V nominal with rechargeables) so you’ll want to regulate that down to 5V before passing it to the GPIO pins. Since VBat is directly from the batteries, the current limit would depend on the batteries themselves.

Are you using the default IO configuration (DIO, Analog In, Analog In, PWM, PWM)? If not, which modes are the various EXT pins set to? (helps with troubleshooting)

[Mr.R_2]

Thanks. First of all, I meant VSW Not vbat (though I think it is still 7.2V. I was thinking about the high voltage as well after I posted).

By the way, something to note (but perhaps goes without saying). for anyone else trying to use the robotic arm assembly. The Wpilib servo vlass uses a slightly different range than the servos prefer. They still work, however, I recommend running them on the Romi without the horns/gripper attached first and then letting them adjust to neutral without power. Servos are powerful (even when browning out) and plastic conponents break and strip easily.

As for the EXT setup… I set it to PWM, PWM, PWM, AI,AI. I can try modifying it and see if that changes things.

[zeequeue]

I’ll take a look on my side as well. I have a bunch of analog sensors that I tested with and they seemed to work.

VSW goes through the regulator, but I can’t remember the exact current limit off the top of my head. The datasheet should have some ino about this, but I’m betting it’s around 2A or so

[Mr.R_2]

Thank you. I will keep you posted on my findings as well. I have some PTC resistors I am going to test before implementing them, but they should in theory keep the Vex motors we have at bay. The srevos do not draw that much current, but the Vex 2-wire motors (we have few of the 3-wire that are safe to use with the Romi) are a bit beastly by hobby motor standards. They have a stall current of something like 3.8 or 4 amps. so, that would be problematic. I know we should not be stalling them with a Romi, but…

[Mr.R_2]

I did just try using the default setup for the analog inputs, and neither worked for me. I have to do some other work, but the brownout issue is easy to test without other hardware. I re-read the power section on the control board website, and the pi can be safely powered externally. I also realized that I am testing with a Pi 4 instead of a Pi 3 (the 4 may draw more power than the 3).

[veg]

You also might check the soldering of the I/O jumpers on your Romi controller for any shorts. It almost sounds as if you have one or more I/O pins shorted to Vcc/GND maybe?

It might be easier to run a few Arduino test programs on the Romi than it would be to take it apart to inspect the underside of the board.

[Mr.R_2]

I tried on a different robot and had similar results. There was an embarrassing error our my code, which we fixed, but also updated to the new version of the Romi interface. I will need to explore powering the servos a bit more, but analog works now.

Thanks so much for your help. Thank you @zeequeue for your help and for taking the time to work this out as well.

Edit: In case anyone else has issues and wants to know which analog devices I tried, the Vex Line Tracker and Sunfounder Analog distance sensor work well.

Also, the new update seems to have fixed the DIO issues we had before. So far, I tried this with a Vex Bumper switch. The Vex distance sensor (Digital IO) is our next test :).

[Mr.R_2]

Hello,
A bit of an update, but I know I am dabbling in uncharted pre-release territory, so if I need to just wait a bit until the documentation is released, I can.

Encoder.get() works well. I will work a bit later on getting kinematics to work, but that seems like it will work well at this point with accurate wheel speeds

The ultrasonic did not work, but since it seems the DIO is working, then perhaps, either my test ultrasonic sensor is not working, the ultrasonic interface is not exposed, or I messed something up in implementation. I will test the ultrasonic sensor on a Vex cortex controller when I get a chance.

Then, I noticed it seems that the gyro, accelerometer, and battery interfaces should be working in this firmware build, so I tried them as well, but did not get too far.

I used the WPI docs for the Accelerometer and Gyro, but they both returned a result of 0 for all variables.

Then, based on [this sim thread] (Robot Simulator not working - Programming - Chief Delphi), I took a look at the examples built into the WPILibrary, but they did not help too much. The simple drive sim example implements the Gyro sim device exactly like the WPILib documentation, and the state-based example got a bit more complicated (simulating an onboard SPI gyro, see code below…), but that did not seem to work either.

My interpretation of the gyroSim as SPI code…

private final Gyro m_gyro = new ADXRS450_Gyro();
private SimDouble m_gyroAngleSim;
...
@Override
  public void robotPeriodic() {
    m_gyroAngleSim =
    new SimDeviceSim("ADXRS450_Gyro" + "[" + SPI.Port.kOnboardCS0.value + "]")
          .getDouble("Angle");
   SmartDashboard.putNumber("gyro", m_gyroAngleSim.get());

The battery level returned a result, but it seemed scaled wrong (~10.12 when the current battery level with rechargeables is really around 7.6).
}

@Override
  public void robotPeriodic() {
      var batteryVoltage = RobotController.getBatteryVoltage();
      SmartDashboard.putNumber("battery", batteryVoltage);      
}

The battery does seem to be working because as the voltage goes down, so does the reported value. I will chart it a bit, and see if I can find the correlation.

I did notice that for both the battery and gyro values the state-space example uses a DifferentialDrivetrainSim() object to update the values. Perhaps that is necessary?

Again, I am fully aware that I may just need to wait until full implementation, updated documentation, or both arrive.

Here is the full code

[Peter_Johnson]

The Romi Gyro will not work with Beta 4 WPILib; we changed the WebSockets layer.

[Mr.R_2]

A bit of an update just in case anyone comes looking. I have implemented the full Romi and robotic arm kit. The analog sensors in the servos are working as well (though you do not have enough inputs for all of them. but, I am not sure they are necessary anyway). I used an external buck converter (set to 5 volts) from VSW to the ground and power busses respectively. For those interested, the documentation says the power path is…
vbat->vrp->vsw->vreg
Vreg will cause brownouts with these servos.
This little bot is incredible.

[s-neff]

Assembly problems on topic?

Because of the brief stock shortage, and desire for alternative colors, I bought the kits individually - including the extended height header and standoffs.

However, the stack up of the extended header and extended standoff don’t work at all. Should I expect the first standoff to just be attached to the PCB? Does Pololu lose solder a different component on the main board when it goes in the FIRST kit?

Step 7 in the WPI docs does not appear to have a photo reference for any of this. Happy to help document, just don’t know what the intent is…

[zeequeue]

This hastily copied image shows the mounting holes for the Raspberry Pi (circled in red)

From Pololu’s site, it looks like the regular stackable female header (Pololu - Stackable 0.100″ Female Header: 2x20-Pin, Straight) uses 11mm standoffs, while the extended female header (Pololu - Stackable 0.100″ Female Header with Extra 0.3″ Spacer: 2x20-Pin, Straight) uses 18.6mm standoffs

[Mr.R_2]

We also have the piecemeal versions but without the taller header. The standoffs seem to perform two functions they raise the heat sink off the 32u4 and they keep the headers in place as the robot moves.

Without them, the first issue can happen and be problematic (but should not be as bad with the extended header) The second is probably more theoretical, but it would cause reboots I expect.

Here is a pic of ours.

@zeequeue I agree those look like the standard standoff.

[zeequeue]

You might be able to use the 18.6mm standoffs with a regular stackable header. I think.

I use the default set of headers with whatever standoffs came in the 32u4 board package (most of my Romis are piecemeal versions )

[s-neff]

This photo has the standard standoff next to the 18.6.
Installed on the board is the extended header.

“Exploded view” follows:

If I remove the extended header, I don’t see any physical contact between the boards (clearances are down to <0.5mm in a couple places lol), so it looks like the standard standoff will work fine. Might be worth escalating back to Pololu to remove those parts from the kits?

Unless there’s camera connections or something on that surface that I’ll actually want access to, in which case we need to fix the standoff length.

[zeequeue]

The FIRST Romi kit doesn’t actually come with the extended headers, just the female socket that is soldered to the control board. On most of my Romis, that works just fine with the standoffs that came with the control board.

Attaching a Pi camera might be a little tight with the standard header, but I think it’ll fit fine (the ribbon cable might touch the board surface). I’ll have to dig up a camera module to try it out

[s-neff]

Oops! You’re right, they’re not listed on the kit page. Pololu - Romi Robot Kit for FIRST - Red

I convinced myself on 1/2 or 1/3 that I needed to buy them using Pololu documentation, but I can’t trace how I did that anymore (lol)

I’ll send the same photos to Pololu, but it looks like this problem is not actually of interest to the wider community. Thanks for the fast replies and clarification!