Quote:
Originally Posted by Foster
And while I can design and code a UDP based system that would send 35 frames a second to the driver station the question becomes "what can I do instead of that". COTS will never replace just sitting down and thinking about the problem and put forth multiple solutions.
|
The question for me is: why hasn't someone just done that?
Once they do and open source it the solution can easily be the equivalence of COTS.
I get that FIRST/FRC may not want to be in that business either but it's clearly well within the scope of the skills the community can bring together. So are we dropping TCP in there just to avoid looking at the gorilla in the room?
If I didn't think the military would immediately grab any work I did on this and put it into drones I might do this myself.
Quote:
Originally Posted by GreyingJay
Knowing when to invent your own and knowing when to go with an established solution is itself an important design skill.
|
I agree there is definitely value in not pushing unnecessarily uphill.
I recently have been helping a mechanical engineering firm to upgrade some data capture equipment that is somewhat high speed but also has many features you could do with a laptop from Walmart.
Their previous solution was very hardware intensive for things that would have been better served from software. It was very custom through the whole process and once it acquired data that was hugely unnecessary.
Surely the folks that designed it showed they were very interested in locking them in and getting to play with all those elements, but it drove the cost per unit over $10,000 and that was likely not necessary.
Surely it is a difficult to capture 1Msps at 24bits for 9 channels differential at these levels cleanly and that's an engineering issue. Pushing that data over a wireless to a Cloud that's actually been done and can be replicated.
So yes it matters not to over engineer - but you can under-engineer if you don't know any better.
In the case of this unit I was working in clearly there was a little of both.
Hopefully when we finish they'll have a COTS data acquisition module which solves the core acquisition issue.
The rest they can filter and modify in software with whatever expendable PC hardware they can find.
I have no doubt that the person that built this originally is a competent developer of FPGA based hardware.
They thought the rest would best be served by things like sticking a Raspberry Pi in there - COTS that makes no sense in this system.
System integration, which is what this is, requires a a wide enough experience to know where the edge of the box is.