Development Process Recommendations

Hello All -
I just joined a new team, they are a new team for this year, they have not done any coding work yet. I just joined and met the team today.
I have never done FTC coding before, i’m a full stack developer, so looking at the directions i understand what is going on (we’ll see)…

The school the kids go to does not have a coding class, so they want to do blocks instead of java.

I started the kids on the initial walk through for blocks. Creating Op Modes Blocks — FIRST Tech Challenge Docs 0.2 documentation (firstinspires.org)

Looking at how blocks works, we need to have the developer machine hooked up to the controller to even load the UI, then for all the actuators we need to also have the HW hooked up and configured for the controller. This seems like a lot of things need to be in place before you can start “coding”. Since it is the first time, they are planning on one bot, so doing this, it would either be in build mode or code mode since both of them would take all the HW.

Is there a better way to do coding/configurations? it would be nice if we could load a config file once hooked up to the parts, then code via the controller without the rest of the HW.

any help or guidance would be awesome, and welcome.
thanks!
mark

1 Like

Greetings, Mark!

Wow, that’s such a great question. Thanks for giving us the opportunity to provide some insight into this process.

First, I’d like to point out that Blocks is a programming language for beginner programmers. Those spunky kids (and adults) who are at the early stages of learning how to program - most of these students are just trying to understand programming “concepts” (like conditional statements, loops, and variables) that the concept of “coding the controller” is so ahead of them it’s foreign. Usually becoming confident enough in their ability to “code offline” (meaning you aren’t constantly needing to test every code edit to see if it actually does what you wanted it to) is something typically reserved for “advanced users”. But, never fear, there’s a solution for that.

This story really starts with the Robot Config. The Robot Config really is something you only have to do once, but unfortunately it does require some minimal amount of hardware to be plugged in. Fortunately for us all of the sensors and servos and motors and things aren’t auto-detected, the only things that absolutely MUST be present when setting up a Robot Config are:

  1. Control Hub - This is kinda necessary since the config lives on the Control Hub.
  2. Driver Hub (or phone) - used to actually enter the config through the DS App robot config UI.
  3. Expansion Hub - The config process needs the serial number of the Expansion Hub module, so it must be auto-detected by the robot config UI in the DS App. The Expansion Hub must be powered and must have the data cable connected between the Control Hub and Expansion Hub.
  4. Webcams - If you’re using a webcam, it needs to be plugged in. The config process needs the serial number of the Webcam so that it can identify the webcam when you assign it names like “Webcam 1” and so on.

Once you have that set up, you can go into the Robot Config UI and auto-detect the expansion hub and webcams, and then save the config. From that point on, you can add motors, servos, sensors, and so on to the config at will (without the hardware needing to be present). You can also then use the on-robot UI to “code the robot” to your heart’s content, even without the extra hardware present (only the Control Hub with the config on it is required).

The kicker is that in order to RUN a program on the Control Hub, those components have to be present. When Blocks attempts to go and initialize the Expansion Hub or a Webcam, and they’re not actually present, Blocks (like Java) will either error out or crash. This is why we don’t really advertise “fill out a complete hardware config, then you can disconnect everything and use the control hub to do your programming” because at some point the kid wants to run the program. And it will crash without the hardware (ExHub and Webcams) present.

There is another alternative that is especially awesome, however, and that’s the Offline Blocks Editor. Yes, just like Java, you can program your Blocks programs without -any- hardware present. Well, at least after you create the editor. Let me explain. Once you’ve configured your robot (meaning you have a complete hardware config containing ALL of the motors, servos, ExHub, webcams, sensors, and everything configured - remember to do this all you REALLY need connected is the CH, ExH, and Webcams) you can then create an Offline Blocks Editor. Now, the catch here is that the Offline Blocks Editor has a “snapshot” of the configuration from your robot - and YOU CANNOT EDIT the config in the Offline Blocks Editor, so once it’s made that’s it. However, when you export the Offline Blocks Editor it creates a ZIP file containing everything you need to edit Blocks programs with the configuration your robot had when it was exported. You can distribute that editor, it’s completely browser based, you can simply extract the editor files to a computer and launch the index.html file to start up the editor. ORTOP has a great writeup on how to export the FTC Blocks Offline Editor. However, REMEMBER, the config is uneditable once you export the offline blocks editor, so if you need to update the config you have to change the robot config and re-export the editor. Ok, I think I said that enough, whenever I distribute an Offline Blocks Editor I get harassed by people constantly asking “how do I edit the config?”, “I want to add another servo, how do I do that?”, and “Just show me how to edit this so I can use it.” and the conclusion I inevitably come to is “I should have never given you that editor.” That’s why I’m telling you how to create it, and giving you the warning.

And, of course, remember that it’s an offline blocks editor. You can’t run the program. However, you can “download” the Blocks you make with the editor, and you can “upload” blocks to the editor, just like you would a real robot. So students I teach can create Blocks, share Blocks, edit Blocks, and then put those Blocks onto REAL robots that can actually RUN the programs.

Ok, I think I’ve put enough here to digest. If you have any other questions or need any clarifications, please feel free to ask.

-Danny

1 Like

Thanks Danny! -
This explanation is perfect. It will also help with the education, and inclusion. I want everyone to be able to write blocks, not just the ones that are using the controller hub.
Time to get the HW list, build a configuration and create an offline editor (and the best part, this is all stuff the kids can help with!).

Appreciate it!
mark

1 Like