Orange Pi alternative for photonvision hardware

Technical PhotonVision
,
1

Hey everyone,

I’m in the early stages of designing a FRC specific vision co-processor board to run photon vision and I’m looking for community feedback of what features matter most to people.

The Goal:
Make a custom co-processor board designed to withstand the rigors of FRC and eliminate common pain points with the typical orange pi setup (large foot print, external power components, SD card, etc)

This board aims to be more reliable by:

  • Removing the potential for the SD card to pop out
  • Removing external components for power (both the type C break out cable and the buck converter)
  • Simplifying cable management with direct 12V power in using WAGO connectors
  • Including one locking type C camera port
  • Including cable strain relief points for better wire management

This board aims to be easier to use and more versatile by:

  • Reducing the physical footprint by ~50%
  • Including support for type-C cameras
  • Including mounting options intended for FRC robots
  • Each camera is on its own USB bus (no more bottle-necked performance when using more than one USB 3.0 camera)

Features:

  • POWER
    • Power draw < 24W
      • Allows for future power via POE from the VH-109 Radio
    • Wago push connector for 12V in
    • Low dropout voltage (6v ideal. 7V min)
    • Reverse polarity protection
    • Overcurrent protection
  • IO
    • 1x RJ45 Ethernet Port
    • 1x USB-C for programming/power
    • 1x USB-A 2.0
    • 1x USB-A 3.0
    • 1x USB-C 3.0
      • Locking type C
    • 12V in via 2 pin WAGO
    • Power LED
    • Activity LED
  • PHYSICAL
    • approximately 65x50x30mm (about half the size of a typical orange pi 5 with case)
    • Comes with 3d printed case (STLs available to print replacement)
      • cable strain relief slots
      • zip tie mounts
      • locking type c for power and camera
      • half in hole pattern for mounting
  • Software
    • Supports photon vision
      • Upload config file when you flash so photon vision loads with your settings
    • EMMC flash for OS (no SD card)

What’s powering the board?
The board will be powered by the Radxa CM5 which is built on the same processor and NPU as the Orange Pi 5 family. Meaning, you will get the same performance as the Orange Pi 5.

What’s the price compared to my orange Pi 5 setup?
Orange Pi 5:

Item Description Cost (USD)
Orange Pi 5 (4GB model) Main Board $80
Plastic Case Mid-range plastic case $10
16GB Micro SD Card Class 10 / A1 $5
Buck Converter (DC-DC) power supply for Orange Pi 5 $10
Total $105

Custom Solution:

Item Description Cost (USD)
Radxa CM5 RK3588-based compute module $124
Custom PCB + Case Carrier board and enclosure $35
Total $159

Questions to the community?

  • Would the goals and features of this board be worth the cost to your team?
  • Are there features on this list you don’t care about?
  • What features are missing which would make the board worth it to you?

I’d love to hear any feedback!

10 Likes
2

If the load fails, how can you recover? With a normal SBC, you can pull the SD, or connect to a monitor and keyboard. Not that I love SD based boards, but it does remove the danger of a brick.

3 Likes
3

Hey Garrett,
This looks like a really interesting project and I’m really excited to see how it turns out! If you want to chat with the dev team about it, I recommend hopping into the PV discord

4 Likes
4

Following……

2 Likes
5

Not sure I understand. If the flashing process fails, can’t you flash it again? And if you just want small configuration changes, you can log in over USB or wifi.

1 Like
6

So typically yes, but if it gets stuck in a state where it can’t enter flash mode then there can be an issue. The preferred solution is a dedicated hardware button to enter flash mode (at least imo) for those style of devices.

2 Likes
7

You know you can put a M.2-2230 SSD card on the Orange PI and have it booted off that directly and don’t have to worry about the SD Card. So the only real pain point is Power/Size/Cooling (you will want to a way to help cool it in whatever packaging you will come up with).

2 Likes
8

For instance, many commercial products require a web page to come up. That is how you provide the image to upload, etc. if the procedure breaks in the middle of writing to the storage, then it could be completely hosed. All systems with no removable storage need to be designed to provide some method to completely start over, and that requires work and testing.

2 Likes
9

For example systemcore has an option to flash thru the web UI, but it also has a way to flash over USB.

2 Likes
10

Based on your description, what you are proposing is not a performance increase, but a size reduction and potential durability increase, correct?
This would come at an approximate 50% price increase. Considering we are only talking about ~ $50, that sounds like a GREAT trade off.
I will be following this project closely.

3 Likes
11

More competition is better, except that maybe you should figure out if you can get the RK3588 instead as it has more performance and peripherals for a slightly higher cost, while being supported by Photonvision for object detection. You should also consider M.2 SSDs for storage, like other commenters mentioned, as eMMC is slow, dies easily, and can’t be upgraded/replaced easily.

1 Like
12

Sure seems like at least a cool idea!

The cost estimates seem a bit on the low side to me - you’d have to have quite a bit of volume to hit $35 for a non-trivial carrier board with components. For example, the Piunora has less scope than you’re considering, but retails for $50.

At least part of the case would likely have to be metal to heat-sink the CPU and keep it running nicely.

Personally, I don’t care about POE (and given how power-hungry the CPU will be, you’ll have to be careful to not pull too much current through that jack).

I’m also not in love with the USB port count. As-is, if I want to hook up many cameras, I’m forced into having different cabling (even if I bought all the same cameras). Sticking to just A or C connectors is something I would prefer - or (more cost but maybe more flex) pair up each 3.0 connection with an A and a C, and let people choose?

Low dropout voltage (6v ideal. 7V min)

5.3v is the benchmark currently :slight_smile:

Other “scope creep” ideas but which would help justify a premium cost for a premium product:

  1. I’m really liking SystemCore’s mini display for helping know basic system status, have confidence things are booted up and running, etc. Unlike consumer products or production systems, indicating status and state in an “obvious” way is a big help while debugging, or identifying issues while in the pit or while setting up on field.

  2. Ability to add in another storage media for data logging (perhaps full image recording) could be really really cool.

  3. Built-in IMU for better on-board localization?

These might require some PV software dev to make work, but there’s plenty of precedent for “small hardware support” things already.

6 Likes
13

I’ll second a built in IMU, that could end up working really well for some of our new experimental localization strategies.

5 Likes
14

Thanks to everyone who took time to reply over the holiday weekend!

Yes, this is the proposition. Maybe with a couple small features to make the value proposition a better deal. However, the focus is to keep it simple and bring value by reducing size and increasing reliability. After all, loosing a match that cost a few to several hundred dollars to a SD card coming out is no fun.

This is ultimately the question to the community.

The current thought would be to take the route that @Sam948 mentioned with a physical button to flash the board and a simple PC app to flash it. The board would be supplied with a linux image with photon vision and the PC app would let you upload your settings during the flashing process just to save a little time.

Yes, this is fair. Though, this is only one part of the reliability aspect IMO. What do others think?

The cost is aggressive. This will not be a money maker for me. My goal is to break even on the boards, not sell for a profit.

What USBs would you prefer to see instead? The connector selection was based off of some of the discussion from previous CD post and surveys around photon vision use. Most people seemed to be using one orange pi with 1-2 cameras. A USB 3.0 Type C lets you use higher res and FPS cameras such as the thirfty cam.

There will be some use cases that this board can’t meet, such as wanting to run 3 type A cameras. But, from what I could gather, most people aren’t using there orange pi in that configuration. Supporting two USB 2.0 ArduCams and / or a USB 3.0 type C camera should cover most teams needs.

However, this is one of the things I want the most feedback on. Do others agree?

This is a fair point although size might start to be an issue. Connectors will take up the most space on the board by far.

I like this idea a lot. I’ll definitely be exploring this. Showing things like the IP address, supply voltage, and CPU temp could be helpful for debugging.

This is interesting. Curious what others think?

I would love to chat more with @Sam948 or someone else from PhotonVison about this. I certainly could route out pads for an IMU and a few of us could populate the IMU for testing. Probably wouldn’t have the software support for this season but I like the potential this has.

A few more details:

  • The goal of this board is not to come in and revolutionize FRC vision processing and steal massive market share from limelight.
  • I see the increasingly critical role that having robust localization is playing in FRC. I want to offer something to help bridge the gap and address common issues / pain points with the current orange pi setup.
  • The goal is to offer a smaller, more robust, and more reliable vision system solution to teams at affordable price.
  • Following that, the target price for this board is aggressive. I’ll be pricing this to break even, not to make money. Otherwise, this price point would be impossible. And, it still will be tight for me to hit as is.
  • The inspiration for this board came from seeing this super tiny radxa carrier board. Just imagine putting this on your robot instead of the orange pi 5 and breakout wires and buck convertor!
3 Likes
15

I like the idea of extra media for image capture. Some of my personal projects (if I ever get to them) start with taking lots of images as the robot drives around and then post-processing them. I would not want to wear the onboard storage, although I guess it could use an USB stick.

1 Like
16

I’ll throw a voice on this, as the choice of USBC for a camera port is a bit odd to me. Since the default recommendations (Arducam/clones) ship with USBA->JST cables, that seems like a more sensible default considering the goals of simplicity and cost/bom reduction.
Using USBC for these requires relatively complex reworking a cable or the camera, which is much more power user focused. Benefiting from USBC also requires measuring and buying a specific (or extra long) cable length, since you can’t get extensions like you can for USBA. This means either plan ahead or buy long and keep extra weight.
Basically, using USBC on one port feels like it’s pushing this as a “1-2 camera per system” solution for teams that don’t especially need a helper board, rather than all-in-one for teams that do need it.

USB count is fine, since three cameras is a viable, solid loadout for most games and the design target. So, having 3 vs 4 is not a dealbreaker, at least from the POV of a one-camera-system team like us. Especially since SystemCore will give a free camera or two of limelight odometry for any blind spots or post-design phase surprises.
However, since a stated goal is eliminate the USB3 bandwidth bottlenecks, adding the 4th camera in to capitalize on the work makes a lot of sense, and is a 25% value add.
Sounds like I’m missing some discussion, but I’ve mostly spotted “one/two camera per system” being a consequence of the OP bandwidth constraints on 3+ full resolution images, and processing overhead causing framerate drops. Since you’re solving the bandwidth issues, and using a more powerful chip, those constraints are lifted and I think a 3-4 camera per pi system makes perfect sense. This is especially true if PV adds NPU april tag detection, which would drop system load even further.

Or, TLDR, my preference would be 3-4 USBA ports, as we’re inevitably doomed to have weight for exactly one PV system (if that), and I don’t see us being able to support using USB-C here.

If we’re going wishlists and feedback:

  • Especially if there’s a stray USB lane somewhere, facilitate limelight-style enclosures with packaged cameras by adding 1.5mm solder points for a JST header somewhere. Then folks can grab an amazon JST connector kit for $10 and a 3d printed case, and compact single-camera solution is done.
  • I’d personally mark passive POE as a non-feature, despite finally having a reliable source. The potential hazard is too high, and active POE is a cost driver with no existing FRC solution.
  • Minimize number of sides with connectors. My pet peeve of pi boards is wrangling cords from every which way, often with irksome mounting repercussions. If it’s all on one side, planning is way easier. But I’ve also designed PCBs… so i get how things get that way.

Otherwise, you’re basically planning all the same things I’d ask for already. Looking forward to this existing. :slight_smile:

3 Likes
17

I agree, cause the m.2 ssd is physically screwed down so it is less likely to fall off, unlike the emmc module Orange Pi sells or a microsd card, while still being relatively replaceable and comes in larger sizes compared to soldered on emmc. You could probably put screws for both m.2 2242 and 2230, as it should in theory fit, and gives teams more choice of ssds.

I think the mini display idea is very good as well, as it easily lets teams know if the device is working and connected properly to the radio. I would just suggest you make the display user replaceable, so that if it burns in or gets damaged, teams can easily replace it, like what happened to some SystemCore alpha testers.

5 Likes
18

Booting an OPi-5 off m.2 SSD is noticeably faster that from a micro sd. It allows for plenty of “extra” storage for a variety of things, and it essentially hard mounted. Hard to find fault with that.

EMMC is convenient, but performance, and reliability, is questionable.

IMHO, hard wired power is the way to go, even if using an external regulator to do it.

4 Likes
19

The reasoning for the type C was to support new cameras, such as the thrifty cam. That was really it.

I was approaching this from the intention that this would be used as a 2 camera system since the processing power of the orange pi struggles beyond 2 cameras. So yes, the bottleneck is lifted from usb3 bus performance. You couldn’t actually make use of 3 usb3 cameras. even two usb3 cameras is probably pushing it tbh.

It’s worth noting that the performance of this setup would be the same as the orange pi 5 since it uses the same processor.

Interesting point on adding the solder pads for an optional jst connection for someone wanting to make their own LL style device.

I think if people are comfortable with a setup intended for 2 cameras then the USB-C is fine. But if people really want more than two cameras then it might be an issue for people. But, I’d argue any orange pi system is optimal at 2 cameras.

20

good idea and good to know!

1 Like