NAR Teaser #1 - Getting a sense of the game

That’s gunna Hertz. Narpe Narpe Narpe!


Cross robot communication? :smiley:

It’s not cross-robot. 19 yes or no questions remaining.

Third party i2c sensor?

Different form of controller.

Any type that isn’t vex controller.

Co-processing with a different microcontroller communicating using the UART port?

The message sounds like: “That’s gunna hurt. Sharp sharp sharp!”

Sharp makes an affordable line of IR (infrared) modulated distance rangefinders (including this one), thus “Hertz”. So I will guess that these may appear on a NAR robot.

Given that the thread is titled “Getting a sense of the game”, I doubt that it’s a huge feature of external processing. Probably an Arduino or similar device reading these sensors to save on analog ports, hooked up over I2C using PROS or Convex.

The I2C port - I think you are right. Different firmware and get a slew of I2C communicating items. If it were serial port that would be an Arduino bridge.

Maybe robot to robot communication using line of sight laser communication? Karthik already said RF inter robot cmmunication is verboten. Line of site laser signals is not what most consider radio frequency. Downside is line of sight. Too hard!

Color sensors to send items automatically based upon color. Not Hertz related though.

Hertz does not imply airflow but maybe diasy chain in an Air pressure sensor for the 20 pneumatics tanks they will probably use. Tell them how many shots are left in the tank.

Or maybe they are looking for some static discharges to randomly reset their Cortex? The wire is going down toward the ground. :o](

I believe the processor to be a raspberry pi.
That could be way off but something cody said on skype gave me the idea.

I want a college team some time to use some serious 3rd party LIDARs on their robots.

I had serious debates between using Rasberry Pi and Arduino. Now I can’t switch.

When I start a team at the college I’m transferring too(hopefully) I’ll do even more in terms of 3rd party sensors and work.

From the cortex wire placement, it’s something related to i2c, tabor. Unless they did something to change the i2c port to serial? But they already said that it wasn’t for inter-processor connection.

But eli

The whole conversation about whipped cream.

whipped cream would go on a raspberry pie

Wow I sound like I am making a huge leap huh?

This is like the FIRST game hints all over again lol

lol so this is 20 questions?
how many large balls are you expecting your robot to hold? :stuck_out_tongue:

I deleted 2 posts out of this thread which were unnecessary & off-topic.

That’s not what this hint is referring to. 18/20

Controller as in input device, no. 17/20

Controller as in micro-controller, yes. 16/20

Bingo. 15/20

I like the Sharp sensors, but uh no. 14/20

External processing?? Now why would we do that, the Cortex has more than enough Hertz. 13/20

Try again, no Arduino bridge nor is that the I2C port. 12/20

Every creature deserves a warm meal. Now evidently my cycloptic colleague informs me that it cannot be done. 11/20

Hertz does not imply airflow but maybe diasy chain in an Air pressure sensor for the 20 pneumatics tanks they will probably use. Tell them how many shots are left in the tank.

Or maybe they are looking for some static discharges to randomly reset their Cortex? The wire is going down toward the ground. :o

No, no and no. 8/20

We did say there would be whipped cream. 7/20

So admittedly I screwed something up here. After careful review, drum roll please I rendered the plug going into the I2C port when it was intended to be going into the UART. That was an honest mistake, not some fancy way of throwing everyone off. Sorry about that guys, will fix.

OscarNVCC & tabor473 pretty much got it.

Other hints include, but not limited to:

  • 3.14159 appearing in the image’s metadata
  • Hertz is a measure of speed, used by processors
  • The annunciation of whipped cream which yes Tabor goes on Pie
  • The revealed area is a circle
  • *Was supposed to be UART obviously visible given the wiring and placement
  • Narpe - NAR Pi Enclosure for Cortex (three times as in the “3” in 3.1415)

So the conclusion of the teaser, NAR’s electronics and programming group has been working hard on a formal Cortex to Pi bridge and a fancy enclosure to house all the needed components in a sleek, sexy and 100% VEXU legal fashion.

We will be doing most of our robot programming using a Java Virtual Machine glued onto a small bare-bones Linux distribution, all running on the Pi using a high-speed UART link. Our processor is a 1.0 GHz ARM and has 512MB of RAM, something like 8000x the Cortex with it’s 64K. And we can now interface with all kinds of USB 2.0 and/or ethernet devices with relative ease.

So yeah…

NAR Proudly Presents

The NARPE - NAR Pi Enclosure for Cortex or “NAR’s little red box”

Want to know what else is inside? Visit our pits at worlds!
In the meantime, like us on Facebook to keep up with the shenanigans, team updates and more!

Red herring alert…

In the words of Chris Carter: “Come On Man!” (sorry for all you international folks who won’t get the reference and do not enjoy the US pastime of NFL football)

College rules seems to limit using that 9.6v battery to give some extra oomph to motors.

Previous answers seems to doscount using a really cool non-Vex sensor setup. Maybe a finer grade (more expensive) accelerometer or gyro or more and different ultrasonic range finders would be cool.

Mentioning you want to do most on the Pi. You would have a basic control loop on the Cortex to receive messages from the Pi which is really contorlling things - very intriguing. Not sure the latency you will get between the two but a very cool idea. One you start getting all the varibales you want bewween the two devices that could be quite a large message (unless you squish it down and pack/compress those bytes or only update upon change but that may make messages tougher to code).

The SD card sticking out probably points to a real telemetry management and/or field mapping capability to me. Lots more memory to play with on the Pi with an SD card.

You could do some better probablistic determination of the robot’s state within a run and store info from run to run rather than be wiped clean (not considering PROS/jpearmean Open firmware options here with some limited flash memory storage capabilties on the Cortex). You could also have a more detailed map of the field and elements with more memory.

Yeah pretty much, I designed the enclosure, Chris is working on a super slimmed down Linux image for us with fancy code uploading and compiling over ethernet and/or wireless (using a USB dongle which we will most certainly not be using during a competition).

I mapped out a super-secret (for now) robot management framework on paper which went over well and Chris and JR are working out the details on the protocol, what commands to send, what data to get back, sensor polling, etc.

Regarding the protocol, I initially had concerns on latency, bandwidth, etc. but everyone around me has assured me that we’ll be fine.

My favorite part of this is that the Pi really is only a co-processor and with the way we’ve mounted it, it’s just an extension of the Cortex. Four cables do everything and they all go into one single UART port on the Cortex. The simplicity is nice, and the design is clean.

As for the legality of doing this, this Q&A I made should have let the cat out of the bag months ago.

I even made a Q&A for battery connections & a Q&A for custom wires.

From the answers I got, not only is NARPE legal, but nothing in it, including the box counts against our material usage. It’s all one big co-processor with a custom enclosure which for all legality reasons is considered part of the sensor as it is non-structural.

Once again, I screwed up on the I2C, feel free to razz me if need be. I tend to get the simple things wrong here and there when dealing with the bigger picture which in this case was what is in the enclosure, not which port it was plugged into :stuck_out_tongue: