Romi OnBoardIO

@jdaming Again, FYI the A button now turns on YellowLED. No need to respond but I thought you should be informed.

It looks like you are off to a good start. Sorry that it took so long to reply. It has been an incredibly busy week. I hope the meeting went well. I am not sure I want to lead you backward if you are beginning to understand the command framework, but if you are still wrestling a bit with things, I created two timed robot examples.

One is in CPP,
One is in Java.

They are much more direct in how they control the hardware. They may not be perfect, but they do work for me.

As for the walk-through, I could take a look when I get the chance. I have watched that video many times to learn the command framework (I watched it live too). One thing to keep in mind, the code they posted came out before the current version of WPILib, WPILibPi, and the Romi image and firmware. So, some things will be a little different (as an example, if memory serves, they do not use Lambdas). I think they did get it working toward the end of the video. You can access the code on the website.

As for the line tracker, some of those are I2C, but the ones we use are analog. We have a bunch of old Vex parts, and though they are expensive, these are working well for us (we have just begun experimenting and are using only one at the moment).

@jdaming thank you for including the ball search command in the code that you shared. I got Photon working, and was in the process of implementing some ball search logic, and it looks like I was heading in the right direction.

I also got a little busy. Thanks for code. Every time I think I have moved forward, I find it is not so. Like Lambdas are not to use statements like if or for. Not from what I see in example just given. Statement ? Action : Action. In my java lessons this (? :slight_smile: is covered under the if description.

I don’t know how the face got in there. (? :slight_smile: is what I typed. Zoom went as expected.

Foget it relace face with : : : As I type that stupid face shows up.

Yes. It is crazy how the system replaces the symbols. Code tags may help. Ironically, lambdas are Java’s functional programming forray. However, yes, they are confusing. In another thread, @jdaming sent me to this video which was incredibly helpful.

Lambdas do use boolean logic. In fact, in the lambdas above, the left side of the lambda tests the condition. If it returns true, the logic on the right is implemented.

If you need something more (using else etc), I wonder if utilizing the ? Operator could help.

Yes, it was unfortunate the java example lumped the operator as being a shortcut to the if. The video is quite good and along with your code I am doing better. Hopefully I will get the IR implemented. Thanks.

I am glad you are making excellent progress.
Forgive me if you understand it well already, but if you are looking for basic java boolean logic implementation. We usually do it like this…

        if (logicalTest){
        } else if (logicalTest){
        } else{

Or, you can use a Switch Statement.

We have the Vex IR sensors working as analog inputs.
You need to configure the IO first in the webUI(or use one of the default ports if you do not change the configuration).

I do understand the if, but the I need to configure webUI that is not so simple. The analog inputs deals with the RobRio not the Romi. No port(0)! My transition to Romi was not one from programming the big bot.
So I know that the web UI lets you configure the 5 external IO pins (and also shows you which WPILib devices/channels they map to in code). There are pin connections to the Atmel or Microchip processor and then there are DIO0-DIO8. I see PWM that go to motors, and Analog not called port 0.
I feel like the one of the infinite monkey’s on the typewriter who after an infinite time will event write Hamlet .

I totally understand the confusion. Before the official release, I was a bit lost in the DIO implementation as well.

There are a few concepts that could help clarify things.

  1. The intent of the WPILibrary seems to be to program the Romi as close to the same as the big bot as possible.
  2. The hardware pins on the Atmel are software configurable (through many levels of abstaction by the time we get to the WPILib interface), and those on the RIo are not.

Enter the web UI as a perfect solution. When you get to the webUI, you can scroll to this section.

In order to change anything, the Pi needs to be writeable. So, if you want to change anything, click writeable on the top.

The pin assignments on the left correspond to where you plug the device in (you need to add power to the power rail which can be done with a jumper on the FIRST kit version.

You use the dropdown menus to set the IO of each pin. The numbers correspond to the port assignment in the software. So, if you use the default config, Pin EXT1 behaves like Analog pin 0 would on the RIO.

So, the constructor for that sensor would be exactly as the example (except we usually make our hardware assignments private, static, and final)…

// Initializes an AnalogInput on port 0
private static final AnalogInput analog = new AnalogInput(0);

Then, you can use it in code just like the examples. It works this way for any of those five pins. You can set it to PWM, Digital Input, Digital Output, or Analog.

Since the Romi strives to be just like the Rio from a coding standpoint, you can use any of the WPILib example projects to learn how to implement something. You just need to remember that though the actual project will not work with the Romi. The syntax for implementing the code will likely be exactly the same in your Romi project (the IMU is a bit different, but even then, once they are constructed, the way you access the data is the same).

This is actually the beauty of abstraction. We do not need to know how the processor works, we just need to know how to tell it to do what we want it to do.

1 Like

If you’re interested in what’s happening on the “bare metal”, this (slightly out-of-date, but still relevant for the default IO pin configuration) document has a little bit more info: wpilib-ws-robot-romi/ at main · wpilibsuite/wpilib-ws-robot-romi · GitHub

DIO pins 0 to 7 are reserved for specific functions on the Romi 32U4 board (wpilib-ws-robot-romi/ at main · wpilibsuite/wpilib-ws-robot-romi · GitHub). Think of these as pins that have already be spoken for and connected to relevant devices. Similarly, PWM 0 and PWM 1 are reserved for use by the onboard motor controllers, so you can think of these as being permanently attached as well.

@Mr.R_2 hit the nail on the head about abstraction. In building out the Romi platform, we wanted to maintain compatibility at the WPILib programming level, where you don’t need to know what the underlying hardware is. If this was bare metal programming, sure, you could configure the port/pin combinations to whatever functions you want. However, we wanted to match what the RoboRIO provided (in terms of physical interfaces, where there are separate groups for DIO, Analog In, PWM), and the abstraction that WPILib allows us to make.


This all very useful information, some of which I was aware off at various levels. So thanks to all. What is very apparent that the backgrounds of the people responding were and are involved in programing the FRC competition robot. Their past experience is critical as to why they understand how to program this new addition. The excitement for me and others with the introduction of the Romi was that more students and mentors could get involved in programming that were not able to do so in the past. But because they have had no experience with WPI libraries the path is difficult.

The point of this post was to help difficulties experienced. It has and will be of considerable help to me. But there are a lot of students who do not get to be principle programmers. To get a universal fluid environment the WPI libraries were created to aid in code development. These libraries aid the experienced programmer but are a source confusion to the novice. So, for those potential future programmers they must face the same struggle unless some sort of meaningful tutorials are available.

I understand some of the frustration. I remember that when we first started programming, I felt a bit lost as well (at that point, I was our programming mentor, and only knew HTML). We have come a long way since then (both our team as programmers and WPILib in accessibility). Have you looked into the Zero to robot tutorial? Things like that have been incredibly helpful. In our rookie year, I read, watched, and sometimes even listened to many tutorials, and I still do. If you or your members/mentors need more in-depth tutorials, perhaps the tutorials listed on the Spectrum website would be helpful.

I feel like in FRC, the devs always wrestle with releasing new helpful hardware and software quickly, and waiting until the documentation is clear. This seems to happen with all vendors as well as WPILib. However, since this is a community-supported effort, many people who do not have the skills to create the new libraries do come here and support those with questions. Even in this thread, we also have some of the main developers lending a hand.

I personally feel this paradigm works incredibly well. However, I understand how it could be difficult at times. The Romi examples are hit doubly with the paradigm. The robot is brand new, and the New Command Framework is also newer (I think it was new last season) than most of the complete tutorials out there. If you want an incredible command framework Java tutorial (though it uses the old command framework) check out this video series from team 4672.

I get that it can be frustrating, but with a bit of time, problem-solving, and asking clear questions, a team can go from zero to trajectories in just a bit of time. We did. It was all thanks to the community, and one of the many things we love about FRC. I feel this progress would not be possible in many other venues.


This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.