Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconfigure interruptions? #39

Open
Peque opened this issue Feb 22, 2018 · 7 comments
Open

Reconfigure interruptions? #39

Peque opened this issue Feb 22, 2018 · 7 comments
Assignees
Labels
Milestone

Comments

@Peque
Copy link
Member

Peque commented Feb 22, 2018

Systick just activates sensors readings interruptions, which are faster; at the last reading we disable sensors readings interruptions and execute the control. This way sensor readings are closer to each other in time. Is the interruption switching (from main to sensors) faster than simply waiting in the systick and avoiding the sensor interruptions? (guess switching requires saving registers etc.)

@cua-cua
Copy link
Member

cua-cua commented Feb 24, 2018

To improve current implemented solution:

  • Synchronization between the control and the distance sensors execution. The ideal situation is to read completely the sensors just before the control execution.
  • The current sensors state machine has 4 states to read each sensor so 16 states triggered by interruption. The time between interruptions is too long and there are a lot of context changes. The reads could be closer.

To analyze:

  • Possible active waiting:
    -- LEDs rise/fall time : 5-9 microseconds
    -- ADC read time: Sampling time cycles (1.5) + 12.5 cycles, with 14 MHz of ADC clock(max config) and 4 channels injected. Check ?
    -- How much free time do we have on systick?
    -- System clock possibilities
  • Disadvantes-advantages of interruptions:
    -- Context change time: ?
  • Sensors reads overlapping

@Peque
Copy link
Member Author

Peque commented Apr 16, 2018

I like the active wait approach. We could simply:

  • Read all while emitters are turned off.
  • Turn on emitter 1, wait a bit, read.
  • Turn on emitter 2, turn off emitter 1, wait a bit, read.
  • Turn on emitter 3, turn off emitter 2, wait a bit, read.
  • Turn on emitter 4, turn off emitter 3, wait a bit, read.
  • Turn off emitter 4.

Also, while we "wait a bit" we can do the raw-to-meters conversion. This way we might not even lose any time.

It also simplifies the interruptions and finally solves the problem of not having all readings as close as possible to the control execution.

@Peque Peque self-assigned this Apr 16, 2018
@Peque
Copy link
Member Author

Peque commented May 1, 2018

Unable to make this work. Moving it to OSHWDem 2018 milestone...

Anyway it is now not so critical, as it seems we fixed the peaks in the sensors readings after the latest changes.

@Peque
Copy link
Member Author

Peque commented Oct 27, 2018

Moved to Portugal 2019 milestone. Added "on hold" label as this method results in less reliable readings. We probably need some hardware changes to improve that (i.e.: add capacitors next to the emitters to provide the required transient power).

@Peque Peque transferred this issue from Bulebots/bulebule Apr 29, 2019
@Peque Peque added the question label Apr 29, 2019
@Peque Peque added this to the OSHWDem 2019 milestone Apr 29, 2019
@Peque
Copy link
Member Author

Peque commented Apr 29, 2019

We will try this approach with Meiga.

If it works well we could consider backporting it to Bulebule. In that case we could take the chance and update the PCB with other changes:

  • Add an ADC reading for motor voltage
  • Slimmer design (thinner tires)
  • More weight to the front
  • New motors/encoders (with 2-cell battery)
  • Pyboard instead of Bluepill?

@cua-cua
Copy link
Member

cua-cua commented Apr 29, 2019

Could you change PCB changes on Bulebule to Bulebule repo?

@Peque
Copy link
Member Author

Peque commented Apr 29, 2019

@cua-cua Yeah, good idea! Bulebots/bulebule#411

@Peque Peque modified the milestones: OSHWDem 2019, Portugal 2020 Oct 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants