00:25 | anuejn | ah i see
| |
00:26 | anuejn | that again depends on the routing machxo fpgas, i presume?
| |
02:25 | Bertl | yup
| |
06:46 | illwieckz | left the channel | |
06:57 | illwieckz | joined the channel | |
07:07 | illwieckz | left the channel | |
07:19 | illwieckz | joined the channel | |
07:39 | se6astian | what exactly needs to be done on the XO2? just connecting the right in- and outputs?
| |
11:43 | Bertl | well, that would work to some degree but probably disable the sensor as the few available connections to the Zynq are already in use
| |
11:45 | Bertl | so what would be required is to handle the protocol (IIC, SPI) on the MachXO2 and somehow communicate the data to the Zynq (basically T731)
| |
15:23 | se6astian | ah, I see
| |
16:00 | se6astian | MEETING TIME, welcome to 2023, anyone around ?
| 16:00 | Bertl | is here
|
16:00 | se6astian | great, how are things Bertl on your end?
| |
16:00 | Bertl | pretty good so far for 2023 :)
| |
16:01 | Bertl | nothing unusual or terribly new to report yet though
| |
16:02 | se6astian | regarding the IMU CSO, it sounds like the lack of IO to ZYNQ dependency is a pretty big showstopper considering T731 has been approached a few times without real solution IIRC, is there a workaround with reduced bandwidth or some other idea how we could get the IMU data without having to jump through a lot of hoops?
| |
16:03 | Bertl | I think a quick hack solution should be doable with a fixed slot cyclic exchange
| |
16:04 | Bertl | i.e. a fixed size shared circular buffer between Zynq and MachXO
| |
16:04 | Bertl | where each bit has a well defined meaning and the buffer size is just large enough to accomodate the required functionality
| |
16:05 | se6astian | sounds interesting, would that have any drawbacks?
| |
16:05 | Bertl | probably a little trickier on the side where we only have one LVDS
| |
16:06 | Bertl | well, it would be constantly active and thus consume some power and it cannot accomodate to any changes (except for re-building the gateware for both ends)
| |
16:07 | Bertl | but I think it should work
| |
16:07 | se6astian | that sounds reasonable, will it mean a different gateware is required if no CSO is soldered on?
| |
16:08 | Bertl | probably not, but it would need to have the correct gateware on the MachXO2s
| |
16:09 | se6astian | right, that sounds like a plan
| |
16:09 | Bertl | another 'quick' alternative might be to run something like I2C (at low speeds) directly over the Zynq/MachXO2 connection
| |
16:09 | se6astian | vup/anuejn would any of this be interesting for you to work on?
| |
16:09 | Bertl | and implement the GPIO functionality as I2C slave in the MachXO2
| |
16:10 | Bertl | that would probably increase the latency somewhat but might be simpler to do
| |
16:10 | Bertl | (and with somewhat I mean significantly ;)
| |
16:12 | se6astian | latency from IMU to ZYNQ?
| |
16:13 | Bertl | latency in both directions especially for the GPIO part
| |
16:14 | se6astian | as I currently see no application where the IMU data needs to control a motor or similar and we just want to dump the motion data I guess a latency is no issue as long as we know the delay or get a timestamp so we can match footage and motion
| |
16:14 | se6astian | but maybe we also need to talk about how/where to store the motiond data?
| |
16:15 | Bertl | yes, the data could be collected on the MachXO2 side and reported back periodically
| |
16:16 | se6astian | looking at the csv format: https://docs.gyroflow.xyz/logging/gcsv/#gcsv-gyro-log-format
| |
16:16 | se6astian | the timing seems to just be listed in ms (tscale,0.001) as first parameter in the list then
| |
16:17 | se6astian | the machxo2 would get the data from the motion sensors with a fixed clk rate I assume?
| |
16:18 | se6astian | and forward that data to the Zynq also with a fixed clk rate so the zynq would need to supply the timestamp then right?
| |
16:18 | Bertl | the data rate depends on the IMU settings and how/when the data is retrieved
| |
16:18 | Bertl | timestamping depends on the transport mechanism used
| |
16:19 | Bertl | in the fixed buffer case we can assume that data arrives at precise moments based on the Zynq clock
| |
16:19 | Bertl | in the I2C case, we probably want to do the timestamping on the MachXO2 side and transfer the timestamp as well
| |
16:19 | se6astian | right
| |
16:20 | Bertl | although that would complicate things a lot compared to just a simple I2C pass through
| |
16:20 | se6astian | anyway, would be a good way forward, lets see if we can interest anyone in working on this, then we can go into more detail
| |
16:20 | Bertl | sure
| |
16:21 | Bertl | do we have anybody to do some actual testing with the IMU?
| |
16:21 | Bertl | because it might be pointless to implement communication and then not use the data for anything ;)
| |
16:22 | se6astian | well there is the https://gyroflow.xyz/ way to stabilize footage
| |
16:23 | se6astian | with the data
| |
16:23 | Bertl | yeah, but that kind-of presumes that the IMU is configured and the data retrieved is valid/good
| |
16:24 | Bertl | what I meant was, there is certainly some testing involved to make sure that the IMU is sending usable data ;)
| |
16:24 | se6astian | true, how could we verify the data at an earlier development stage?
| |
16:24 | se6astian | controlled motion with a gimbal?
| |
16:25 | Bertl | yeah, something like this is probably a good start
| |
16:25 | se6astian | I should be able to assist on that front
| |
16:25 | Bertl | have some servos/motors to move the camera in a predictable way
| |
16:25 | Bertl | then do some (data) recordings and see how that matches
| |
16:26 | Bertl | idealy some comparison device would be great, e.g. a pi-zero with an IMU or so
| |
16:26 | se6astian | good idea
| |
16:27 | Bertl | btw, that might also be a quick way to add this functionality without the IMU CSO if we only want to test whether this works or what's required setting wise
| |
16:27 | Bertl | (especially if we use a similar/identical IMU on the pi)
| |
16:28 | se6astian | I guess most use the same LSM6DS3H chip yes
| |
16:28 | se6astian | or the replacement
| |
16:29 | se6astian | https://www.sparkfun.com/products/18020
| |
16:30 | Bertl | we might even be able to simply rewire the IMU CSO to the PMOD port at the back of the camera for testing
| |
16:32 | Bertl | that is, if the main goal is to test the IMU and the usability of the collected data
| |
16:32 | Bertl | have to check schematics, but I remember that we used the I2C paddles on the camera itself, so that might work
| |
16:34 | se6astian | sounds good, lets see if this topic picks up some momentum
| |
16:34 | Bertl | yep
| |
16:34 | se6astian | anything else for today? or anyone else around?
| |
16:35 | Bertl | nothing from my side for today
| |
16:37 | se6astian | ok then! many thanks! MEETING CONCLUDED!
| |
16:37 | Bertl | thanks for moderating!
| |
16:39 | se6astian | my pleasure!
| |
19:01 | Chooks | joined the channel | |
19:01 | Chooks | Unfortunately I do not have the knowledge to help you on the subject.
| |
19:01 | Chooks | Gyroflow has also developed an external solution for cameras without an imu (steadXP style).
| |
19:01 | Chooks | In case it doesn't work there is always this solution to integrate it on top of the camera. But let's say it's stupid if an IMU is present inside.
| |
19:02 | Chooks | https://github.com/gyroflow/flowshutter
| |
19:02 | Chooks | On our side, we will be able to start working again with you on the enclosure. We plan to pour a slab in my cellar in a few weeks to install a fablab.
| |
19:02 | Chooks | We have all the parts to install a CNC for aluminum and we will be able to help you with the protoyping of parts within 2-3 months.
| |
19:03 | Chooks | Â It could be interesting to know if the enclosure can be machined on a 3-axis cnc and have your feedback from the first machining if you were present on site.
| |
20:50 | Bertl | Chooks: yay! sounds great!
| |
21:28 | se6astian | Hi guillaume, great!
| |
21:29 | se6astian | all cnc parts can be done with 3 axis, I specifically designed the parts to be "simple" and sturdy and functional
| |
21:30 | se6astian | lets have a chat about this soon as I contacted the cnc manufacturing plant for a small volume batch for early adopters just days ago
| |
22:44 | Chooks | left the channel |